C# – NHibernate: uninitialized proxy passed to save() and cascade

cnhibernate

I keep getting an NHibernate.PersistentObjectException when calling session.Save() which is due to an uninitialized proxy passed to save(). If I fiddle with my cascade settings I can make it go away, but then child objects aren't being saved.

The only other fix I have found is by adding the following to my DefaultSaveEventListener.

    protected override bool ReassociateIfUninitializedProxy(object obj, global::NHibernate.Engine.ISessionImplementor source)
    {
        if (!NHibernateUtil.IsInitialized(obj))
            NHibernateUtil.Initialize(obj);

        return base.ReassociateIfUninitializedProxy(obj, source);
    }

This is obviously not an ideal solution.

Any ideas?

Best Answer

There mere presence of a custom DefaultSaveEventListener subclass containing no overidden or extended behaviour is enough to trigger this exception for me, using the following configuration Xml:

<event type="save-update">
    <listener class="MyNamespace.MyCustomSaveEventListener, MyAssembly" />
</event>

I am continuing this discussion in this question.

Update:

I had mistakenly derived from DefaultSaveEventListener instead of DefaultSaveOrUpdateEventListener, changing the superclass made this problem go away for me.

Related Solutions

.net – NHibernate ISession Flush: Where and when to use it, and why

Briefly:

Always use transactions
Don't use Close(), instead wrap your calls on an ISession inside a using statement or manage the lifecycle of your ISession somewhere else.

From the documentation:

From time to time the ISession will execute the SQL statements needed to synchronize the ADO.NET connection's state with the state of objects held in memory. This process, flush, occurs by default at the following points

from some invocations of Find() or Enumerable()

from NHibernate.ITransaction.Commit()

from ISession.Flush()

The SQL statements are issued in the following order

all entity insertions, in the same order the corresponding objects were saved using ISession.Save()

all entity updates

all collection deletions

all collection element deletions, updates and insertions

all collection insertions

all entity deletions, in the same order the corresponding objects were deleted using ISession.Delete()

(An exception is that objects using native ID generation are inserted when they are saved.)

Except when you explicity Flush(), there are absolutely no guarantees about when the Session executes the ADO.NET calls, only the order in which they are executed. However, NHibernate does guarantee that the ISession.Find(..) methods will never return stale data; nor will they return the wrong data.

It is possible to change the default behavior so that flush occurs less frequently. The FlushMode class defines three different modes: only flush at commit time (and only when the NHibernate ITransaction API is used), flush automatically using the explained routine, or never flush unless Flush() is called explicitly. The last mode is useful for long running units of work, where an ISession is kept open and disconnected for a long time.

...

Also refer to this section:

Ending a session involves four distinct phases:

flush the session

commit the transaction

close the session

handle exceptions

Flushing the Session

If you happen to be using the ITransaction API, you don't need to worry about this step. It will be performed implicitly when the transaction is committed. Otherwise you should call ISession.Flush() to ensure that all changes are synchronized with the database.

Committing the database transaction

If you are using the NHibernate ITransaction API, this looks like:
tx.Commit(); // flush the session and commit the transaction
If you are managing ADO.NET transactions yourself you should manually Commit() the ADO.NET transaction.
sess.Flush();
currentTransaction.Commit();
If you decide not to commit your changes:
tx.Rollback();  // rollback the transaction
or:
currentTransaction.Rollback();
If you rollback the transaction you should immediately close and discard the current session to ensure that NHibernate's internal state is consistent.

Closing the ISession

A call to ISession.Close() marks the end of a session. The main implication of Close() is that the ADO.NET connection will be relinquished by the session.
tx.Commit();
sess.Close();

sess.Flush();
currentTransaction.Commit();
sess.Close();
If you provided your own connection, Close() returns a reference to it, so you can manually close it or return it to the pool. Otherwise Close() returns it to the pool.

SaveOrUpdate Vs Update and Save in NHibernate

Chapter 9 covers all of this better than I can:

http://nhibernate.info/doc/nh/en/index.html

But cliff notes:

Save() takes a new object without an identifier and attaches it to the session. The object will be INSERT'd.

Update() takes an existing object that has an identifier but is not in the session and attaches it to the session. The object will be UPDATE'd.

SaveOrUpdate() looks at the identifier and decides what is necessary in the above.

SaveOrUpdateCopy() is special in that say you have two objects with the same identifier -- one in the session and one not. If you try and update the one not in the session an exception is thrown normally (you are now trying to attach two objects that represent the same persistent object to the session). SaveOrUpdateCopy() copies the non-session object state to the session object state.

I'm not sure how you are going to use NH, but for a lot of cases all you need is Save(). The session is doing ALL of the work necessary to know what has to be updated and simply Flush() or a Commit() does everything you need.

Best Answer

Related Solutions

.net – NHibernate ISession Flush: Where and when to use it, and why

Flushing the Session

Committing the database transaction

Closing the ISession

SaveOrUpdate Vs Update and Save in NHibernate

Related Topic