I understand that the secondary cache stores objects in a disassembled state, but I don't understand why. Wouldn't it be easier to store the object in its assembled state then return the actual object when it is needed? Or if there are problems with returning the original object, then why not return a deepCopy?

I only ask because I'm working on a project where it would be much better if the secondary cache could return the original reference to an object (like the session-level cache) rather than an assembled duplicate. I know this isn't Hibernate's behavior, but I'm just wondering why.

Peter Dolberg

Because Hibernate implements transaction-scoped identity and every concept in Hibernate has been designed around this fact.

and what would you do when two sessions refer to the same object/collection - which one should win those updates ?

I guess what I was looking for is a way to get the same behavior from Hibernate even when I close a session and open a new one. If I try to load the same object twice from the same session then I get back the same object reference each time. If I load one in one session, close the session, then load the same object in another session, then I simply get a duplicate. I was hoping that there was a way to avoid getting a duplicate.

The only way to consistently get back the same object reference is inside a single session, and with a multithreaded web application this means sychronized access to a single session for the whole webapp. This seems like it would be a rather bad bottleneck performance-wise.

As for who wins the update battle, is there no way to prevent objects from getting updated unless I call an explicit session.update()? In that case the session that I call that method on would win.

session.update is related to detach instance, not UPDATE statement

TOPLink does this, and as you have guessed, it results in astonishingly poor performance in a multi-threaded application.

This is of course a patently false statement. TopLink offers much, much, more flexiblity and options on how to control access, caching and synchronization.

- Don

Hey Donald, now giving Hibernate support in your free time? :)

Well, I can't seem to get any of the alleged flexibility to work. Invalidating cached entries doesn't work reliably (and cannot work in all cases because the actual mapped objects are cached, misbehaving code might have references to the objects).

Also, there are some bugs in the version that I'm using that cause it to return incomplete result sets due to incorrect useage of weak references. I'm not sure if that's a cacheing issue.