hibernate first level cache in clustered environment

Question

First level cache in hibernate is maintained on session object and within the boundary of same JVM. It is a mandatory cache that is used by hibernate. I am worried about it as how I will manage the it in clustered environment. Multiple nodes will have their own first level caches (equal to the number of sessions). At a single JVM, one entity can be a part of different session but transaction manager, optimistic locking handle the situation.... But how will we manage the it in clustered environment

1) an entity can be modified in the first level cache of two different nodes causing stale data issue, data lost issues.

2) If we use optimistic locking.... it will be hard to recover the transaction and also it can affect other usefull transactions on other nodes.

3) We can not take pessimistic lock for each and every transaction. It will kill the usefullness of hibernate caching.

4) Setup of Isolation level also will not work as transaction management is done by the hibernate application itself and boundaries of transaction management is one JVM.

Answer 1

Your very first statement is not correct, first level cache in hibernate is not maintained within the boundary of the same JVM. It is maintained within the boundary of a hibernate session.

Hibernate treats sessions (entities in sessions, this is the first level cache) separately, even within the same jvm, you can have multiple hibernate sessions in one jvm.

The question you have about entities being in different first level caches on different nodes in cluster is the same question as to what happens with these entities within two session on the same jvm.

May be you are not getting error but if nodes are different than it is not an error free arrangement. Transaction management is done by the hibernate application itself. It does not use database transaction management (except in case of pessimistic locking). Boundary of isolation level is single JVM.

Transaction management in hibernate directly maps to DB transactions, the "hibernate transaction start" is marked simply by calling the "db transaction start" (either over JDBC or JTA). Regarding the isolation level, this has nothing to do with jvm and is not bound to it.

To your other question

Cant you use different isolation levels on different nodes???? If yes??? what will happen.... If no??? on which node you will get an error message????

This depends on precise sequence of the db statements executed and on the isolation level set either globally or withing the DB transaction.

Answer 2

Fist level cache doesn't produce stale data, I've been using JPA+Hibernate in clustered environments without any issues related to it. The important thing is the isolation level of your transaction. I you don't want the other node to read uncommited data, make sure you work at least with READ_COMMITED level.