Hi,
I have a question about the first level cache (Hibernate Session).

Scenario:
I have 2 tranactional methods usin CMT and Hibernate Session is made to use the CMT Transaction context. Both methods update the same hibernate object and do so like this.

method(PersonDTO personDTO, int strategyType) where "method" is method1 and method2 and are logically doing the same thing (i.e. retreive and update Person as a part of their transaction) as follows


a. Retrive the person using Session.load() method
b. Identify what attributes of person neeed to be updated based on
the strategy type and transfer this attribute values from the DTO to the Person Hibernate object which is now a persistent (not detached) object.
c. Rely on the JTA transaction to close the session and therefore commit the changes made to the persistent Person object.

Question:

If one thread calls method1 and the other thread calls method2 at the same time such that method1 commits the changes to the Person just after method2 has loaded the Person but before method2 commits the transaction, what will happen when method2 commits?

Would it get a dirty read exception assuming we have setup optimistic locking and concurreny strategy as Version meaning there is a Version column in the Person table. Does Hibernate compare updated persistent object to the copy of Person in the database? Or is there a pool of persistent objects that Hibernate maintains in its first level cache beyond the transaction scope and therefore beyond the Session scope in case of a JTA transaction?

Does each transaction see its own copy of the persistent object and therefore during commit overwrites what other transaction just commited?


How does it work?

Assuming each method just creates its own session for the unit-of-work.
1) No version attibute - The last one the to the update wins.
2) With version attribute - The second commit will throw an exception indicating the update was no-possible due to optimistic locking.

Enable SQL you will see the update SQL include the version column and number argument in the where clause. If its does not match then no update has occured as the record has been updated by another client.

From what you have described, it seems like Hibernate always compares the updates to the persistent object to the corresponding row in the database and if it is being updated by another method in a JTA transaction using Hibernate (thereby incrementing the version number of the Version column) it will detect the dirty read.

However I wanted to know what the first level cache really contains. If 5 different methods load 5 different objects each from the database in their own transaction and if now a 6th method tries to access one of these 5 objects in its own transaction, is that object available in the first level cache or is it loaded from the database. In other words does each method have its own copy of the cache and therefore sees only those objects that it has loaded and not objects that are loaded by other methods (i.e other 5 methods in this e.g)?

Your reply is appreciated.

Create a session for each unit-of-work thus each method will load the object in its own session (and hence its own session cache) so there is no effect as they are separate from each other. Please note that the session is not thread safe. So if we are talking about 5 threads running through the same, say DAO, methods then each should have there own session, either on the stack or in a thread local. They are separate and cannot see whats in the other local instances of the session object's cache.

The behavior you are describing of associating a new session with each unit of work should automatically happen if I use SessionFactory.getCurrentSession() which will use the JTASessionContext if called once within a JTA transaction right?

This is what the Javadoc for JTASessionContext says

public class JTASessionContext
extends Object
implements CurrentSessionContext
An implementation of CurrentSessionContext which scopes the notion of a current session to a JTA transaction. Because JTA gives us a nice tie-in to clean up after ourselves, this implementation will generate Sessions as needed provided a JTA transaction is in effect. If a session is not already associated with the current JTA transaction at the time currentSession() is called, a new session will be opened and it will be associated with that JTA transaction