Hibernate version:2.1.6


I have a detached instance of an object that has had modifications made to it.

I reassociate the instance with a new session using session.update( myObject ).

The interceptor onFlushDirty() does not get called back with "valid" information (the previous state is not there for comparions).
This makes audit logging fail for any case where we try and persist a modified detached object. (Very common in web apps and 3T GUIs)

Nick

Use a Long Session approach to implement your Application Transaction, not Detached Objects.

Long Session? Any details would be great {:-)
I have both the ref docs and HIA

Nick

Never mind, I found it.

I didnt realise you could close the underlying JDBC connection while still keeping the session alive.

Thanks

Nick

OK, so Ive looked at this, and this is an option.
However, its making work in the case where my session is held on the EJB tier, and now Im having to hold yet another user ID --> Session mapping.

Why doesn't the interceptor get called back when saving a reattached instance with modified data?

Given that some of the users are coming from the web, I now not only have an HttpSession hanging around in memory until it times out, I may also have a Hibernate Session hanging around.

As you stated in the book, the first approach should be session per request, and I think this is the simplest, and most effective option. However, passing domain objects back and forth between the tiers is a common occurence (unless you want to force DTO objects everywhere, which is a duplication of code in my view, expecially when you have a domain model you want/need to work with on the various tiers).

Is there any way to get Hibernate to call the Interceptor back with valid data when saving a modified reattached instance?

Nick

Because the new Session does not have the original data, it was closed with the first Session. Thats why we have both concepts. There is no third way. The correct implementation of Long Session in a three-tiered environment (without colocation of the presentation and business/persistence layer in the same JVM) is a Stateful Session Bean that represents the persistence context.

Thanks Christian.

How would you go about implementing if when the Web server and EJB container are one and the same (JBoss). Why would you do it differently in this case (same JVM) ?

Nick

There is a good explanation in chapter 8 in HiA, at the end of the AppTx implementation.

That doesnt give a reason as to why you would do things differently if the web tier and EJB tier are collocated (Im referring back one of your previous replies).

I have no problem using stateful beans with the Hibernate session being stored there.

Were you saying that if the EJB and Web tiers are collocated, you would do something different in this scenario?

Thanks for the help

Nick

OK, now that Ive been thinking some more about this, this doesnt actually solve anything, it just moves the session state in to the web tier now - rather than having to hold a Hibernate session map in the EJB tier, I am now pushing the state management in to the web tier - the web "user" has to keep a reference around to a specific stateful EJB.

Ive been thinking about load the object on the stateless EJB tier, and then simply running through every property/collection on the object, and doing:

original.setFoo( newVersion.getFoo() );

While ugly, this will at least trigger the interceptor to audit everything properly, and without the need for stateful connections.

Is there no way to get Hibernate to do a select before update and then call the interceptor?

I've read (twice) the chapters in HIA about application transactions, and everything seems to point to using detached objects in our stateless EJB/Web environment. Great.

If only the interceptor was called back with the previous state data when attempting to attach and update a previously detached instance, this would be a working solution.

However, the Inteceptor doesnt get called back with previous state data, so this prevents all history logging / data auditing. Something which is a key feature (and a great benefit for debugging apps once deployed).


Is there no way to perform a "working" dirty-check on the detached instance? Surely we cant be the first to want to implement this functionality?

Somehow my point didn't make it, so I'll try to simplify it: No, there is no way, unless you use the Long Session implementation and forget about the Detached Objects.

Your point made it {:-)

But my point didnt (since I didnt state it):

Dettached object usage between presentation and EJB tiers is common.
Everything works well, except for the Interceptor.

It would be great is Hibernate could do a dirty check and call the interceptor with "previous" data (yes, this would involve a read), but the audit trail is too important not to have it. Triggers are not an option here.

So, maybe I should log it as a bug, or a feature request ? {:-)

Nick

There is a wiki on how you can implement something similiar yourself http://hibernate.org/161.html. Also, Hibernate3 events will make the above approach somewhat easier.

Ah {:-)

Now that's what I was after.

Many thanks

Nick