I am a new user of Hibernate:

Following on from 'Nearly impossible to synchronize properly in Hibernate', with slightly different questions:

To restate, optomistic locking is best, but deadlocks or stale objects exceptions must be detected, caught and (probably) re-tried. Are these obvious Hibernate exceptions which can be caught directly?

I have a very large data set (across 5 tables) that I want to keep in
memory for improved performance and regular accesses, with a prinicpal parent table, and a number of child tables.

By caching the parent and children objects, will multiple sessions access the SAME physical object, or copies of that object? Do all child collections remain the same physical objects or different collections, containing the same (cahced) objects?

If two threads (from http servlets) attempt to access a child relation 'at the same time', what occurs? Does the single collection object get updated by both threads?

If >1 thread can access the same collection object, this may cause concurrent modification exceptions on any iterators on the base collection. This would be a BAD thing.

If each thread has different physical objects/collections, how does initialised collections (from the cache) get copied into each thread's version of the collection without re-querying the database. Requerying would be a BAD thing as the collection is large, and most data is needed.

If caching a parent object, when would the child object collections be updated with results from multiple threads? Equivalent to read-dirty, read-committed and other isolation levels. Obviously, in my scenario, I would not expect to continuously re-query the child collection from the database to detect the latest child objects.

I think a general document providing Hibernate guidelines for multi-threading operations would be very useful!

Thanks.

(1) There is always a distinct set of objects for each session - caching or no caching (just because you are used to working with other broken cache implementations, doesn't mean that ours is)
(2) Caching strategies for collection roles are configured seperately to caching strategies for entities but of course (1) holds for collections also
(3) Hibernate was designed by people who know something about threadsafety and, of course, does not suffer from any of the Bad things you mention

Thanks - obviously we don't want a broken implementation, but I would like a little more detail to ensure that the application design takes the correct approach.

1) Each session (thread) get's it own distinct 'first-level' entities. Are these instantiated from cache (by clone/copy?) or database (assuming cache enabled) ?

2) If a cached entity contains an instantiated child collection, would all these copies contain (a copy of) the instantiated child collection, or an un-instantiated one? Are the child objects cloned/copied at this point (BAD, very slow), or when accessed/modified?

3) For child collections (containing 'second level' entities), are these instantiated from cache or database (assuming cached entity has an instantiated child collection to start with).

4) I note that the 'version' value of the parent is changed when a collection is updated (by add/remove), then would this introduce considerable 'serialisation' issues with multiple threads add/remove from child collection?

5) When and how does the cached child collection get updated to contain the updated objects, added or removed entities?

Thanks again.

Maybe just me, but I thought my previous post already answered these questions.

Yes, every session has its own distinct set of instances. cache or no cache. association or no association. whatever. Just like I said in the previous post.

And yes, of course Hibernate uses the cache to resolve associations. And of course Hibernate updates its own cache when it changes something. And no, its not broken, the cache concurrency strategies do actually work. Yes, even for collections (where we use eviction to ensure consistency with the database).

If thats not good enough, or you don't believe me, look at the code.

Sorry if I'm being a bit brief here, but this is baby stuff to get right.

hmmmm.

Man I can be a rude bastard sometimes ;)

Max made a comment about grumpy Ozzies once :-)