Hibernate does not control any concurrency between Sessions. It’s the DB who does concurrency control.
Therefor how can locking help me? the problem occurs when 2 different sessions are not sharing the same data since they hold separate caches…
That’s not really a problem. Even if you get the latest state of a row with JDBC, some other transaction can still come and modify the record. You can use pessimistic locking if you want to prevent updates to a certain row.
So, it seems that the only way of dealing with this is by deleting the data that was saved by evict or by clear, no?
Nope. Pessimistic or optimistic locking can help you with that.
It is much easier for me to run ‘clear’ at the end of each transaction, rather than running evict for each object that was pulled.
You don’t need to clear the Session after commit. You only need to do that if you don’t want the entities to be managed anymore.
is there a run time difference if I use clear to clear X object that were just saved on the cache, or if I run evict on each of them separately (which means to run evict X times)?
It’s the same with
java.utilMap. Calling clear is faster than calling remove N times.