NHibernate ISession.Save() - Why is this persisting my entities immediately?

Question

I am creating a large number of entities with NHibernate, attaching them to my ISession, and then using a transaction to commit my changes to the database. Code sample is below:

ISession _context = SessionProvider.OpenSession();

//Create new entities
for(int i=0; i<100; i++)
{
    MyEntity entity = new MyEntity(i);

    //Attach new entity to the context
    _context.Save(entity);
}

//Persist all changes to the database
using(var tx = _context.BeginTransaction())
{
    //Flush the session
    tx.Commit();
}

I was under the impression that the line _context.Save() simply makes the ISession aware of the new entity, but that no changes are persisted to the database until I Flush the session via the line tx.Commit().

What I've observed though, is that the database gets a new entity every time I call _context.Save(). I end up with too many individual calls to the database as a result.

Does anyone know why ISession.Save() is automatically persisting changes? Have I misunderstood something about how NHibernate behaves? Thanks.

***EDIT - Just to clarify (in light of the two suggested answers) - my problem here is that the database IS getting updated as soon as I call _context.Save(). I don't expect this to happen. I expect nothing to be inserted into the database until I call tx.Commit(). Neither of the two suggested answers so far helps with this unfortunately.

Some good information on identity generators can be found here

This is the expected behaviour, the `Save` is being executed outside of the `Transaction`. The correct answer should be @StuffHappens down below. — THBBFT, Jun 12 '16 at 19:49
@THBBFT, Being outside of the transaction does not cause the save to be sent to database. StuffHappens gives not the correct answer as for why it gets inserted at `Save` call. This answer is just ensuring the inserts will get rollback-ed, but that was not the OP concern. And its edit further confirms it. — Frédéric, Jun 18 '17 at 17:59

score 7 · Answer 1 · answered Jun 26 '11 at 16:37

7

Try:

using(Session _context = SessionProvider.OpenSession())
using(var tx = _context.BeginTransaction())
{
    //Create new entities
    for(int i=0; i<100; i++)
    {
        MyEntity entity = new MyEntity(i);

        //Attach new entity to the context
        _context.Save(entity);
    }

    //Flush the session
    tx.Commit();
}

answered Jun 26 '11 at 16:37

StuffHappens

6,457
13
70
95

Trying to get this to the top. – THBBFT Jun 12 '16 at 19:49

score 6 · Accepted Answer · edited Jun 17 '18 at 01:16

Which identity generator are you using? If you are using post-insert generators like MSSQL/MySQL's Identity or Oracle's sequence to generate the value of your Id fields, that is your problem.

From NHibernate POID Generators Revealed:

Post insert generators, as the name suggest, assigns the id’s after the entity is stored in the database. A select statement is executed against database. They have many drawbacks, and in my opinion they must be used only on brownfield projects. Those generators are what WE DO NOT SUGGEST as NH Team.

Some of the drawbacks are the following

Unit Of Work is broken with the use of those strategies. It doesn’t matter if you’re using FlushMode.Commit, each Save results in an insert statement against DB. As a best practice, we should defer insertions to the commit, but using a post insert generator makes it commit on save (which is what UoW doesn’t do).

Those strategies nullify batcher, you can’t take the advantage of sending multiple queries at once(as it must go to database at the time of Save)

I think this may be the issue actually. I currently have: set in my config files. I will test this evening and mark as answer if thats the issue. Thanks! — JMc, Jun 27 '11 at 06:47
I had been using identity as the Id generator which seems to be the cause of my problem. I'm now looking into suitable alternatives for a Unit of Work/Repository pattern where I want to explicitly flush the session myself after associating many entities with the ISession first. Thanks. — JMc, Jul 05 '11 at 07:47

score 2 · Answer 3 · answered Jun 26 '11 at 20:12

2

You can set your batch size in your configuration:

<add key="hibernate.batch_size" value="10" />

Or you can set it in code. And make sure you do your saves within a transaction scope.

answered Jun 26 '11 at 20:12

Peter

27,590
8
64
84

score 1 · Answer 4 · answered Jun 26 '11 at 21:00

Try setting the FlushMode to Commit:

ISession _context = SessionProvider.OpenSession();
context.FlushMode = FlushMode.Commit;

peer's suggestion to set the batch size is good also.

My understanding is that when using database identity columns, NHibernate will defer inserts until the session is flushed unless it needs to perform the insert in order to retrieve a foreign key or ensure that a query returns the expected results.

score 0 · Answer 5 · edited Jun 17 '18 at 01:18

0

What about :

ISession _context = SessionProvider.OpenSession();

//Persist all changes to the database
using(var tx = _context.BeginTransaction())
{
    //Create new entities
    for(int i=0; i<100; i++)
    {
        MyEntity entity = new MyEntity(i);

        //Attach new entity to the context
        _context.Save(entity);
    }

    //Flush the session
    tx.Commit();

}

edited Jun 17 '18 at 01:18

hazzik

13,019
9
47
86

answered Jun 26 '11 at 16:39

Tristan

8,733
7
48
96

score 0 · Answer 6 · answered Jun 27 '11 at 06:52

Well

rebelliard's answer is a possibility depending on your mapping
you are not using explicit transactions (StuffHappens' answer)
default flush mode is auto and that complicates things (Jamie Ide's answer)
if by any change you make any queries using the nhibernate api the default behaviour is to flush the cache to the database first so that the results of those queries will match the session entity representation.

NHibernate ISession.Save() - Why is this persisting my entities immediately?

6 Answers6