Need help with Hibernate? Read this first:
http://www.hibernate.org/ForumMailingli ... AskForHelp


I'm using detached objects and I just noticed that an object that is saved in the scope of a transaction, and thus gets its identifier, will not lose it if the transaction is rolled back. That means that, depending of the way you do it, in the worst case you have to keep aware of all new identifiers that have been assigned to any new objects who may be referenced from outside the transaction, and then set them all to zero (or whatever) on rollback.

Now if you come to think of it, this happens not only with the identifiers, but with any property that, according to business rules, gets changed in what ultimately comes to be a rolled back transaction.

So either you have a very clean Business Facade and you just pass it copies of the objects you have on your hands, or you risk having their state corrupted.

Is is just present panic or does this blur the whole transaction scope thing, and the more object-oriented and abstracted from the persistence medium you are, then the more subject to all sorts of side-effects you'll also be?

Help a lost soul.

Thanks,
Luis

All of our entities implement a pattern similar to IEditableObject. They do implement IEditableObject so that they can be edited in a control like a PropertyGrid or DataGridView and the control can "roll back" its changes via CancelEdit(), but this other pattern is in addition to it.

Essentially, our entities include a protected property containing an object which tracks original values, similar to how IEditableObject implementations track original values. One of these "OriginalValueTracker" objects is associated with each entity, and is created by the entity's constructor. In addition to BeginEdit(), EndEdit() and CancelEdit() methods, it has an Edit() method that is called by each entity property's setter, which passes the original property value. The tracker keeps that original value if it doesn't have one yet for that property, so that in only keeps each property's original persisted value, no matter how many times it gets modified before the transaction is commited or rolled back.

Then, when the session's transaction is committed, OriginalValueTracker.EndEdit() on each entity in the session is called via Reflection (since we don't want application-level code messing with this tracker object). EndEdit() simply clears the original values it saved. When the session's transaction is rolled back, OriginalValueTracker.CancelEdit() on each entity in the session is called, again via Reflection. CancelEdit() sets a protected boolean flag on the entity indicating that original values are being restored and then proceeds to set the original values back on their associated properties. The entity property setters check the boolean flag, recognizes that original values are being restored, and suppresses validation (this is necessary because original values may actually be illegal in some cases).

BTW, each of our entities has two of these OriginalValueTracker objects -- one to keep the original persisted values, and one for use by the normal IEditableObject implementation.

Yeah, that's kind of similar to what I had in an old Persistence Framework of my own that I was developing, I kept a clone()d object along the way. However, keeping two objects like that, and restoring relationships with other objects, etc. ... I can't really foresee the implications with the Hibernate session. I think it would be a very interesting *option* to include in NHibernate.

What I wonder is if people are really aware of the implications of this new object oriented persistence model and if they're not leaving gaping holes in their architectures. These issues seem rather complex to me and some kind of white paper on this issue by some guru would really be welcome in my opinion.

Yeah, we're coming to grips with this more as we try to perform independent caching for various reasons. Corruption can appear when keeping any detached entities for any amount of time beyond a single "application session" (a series of NHibernate sessions interspersed by user think time), and any rollback occurs ...