I'm about to move to a inter-session cache for performance tuning.

Thinking through the implications it occurs to me that this might change the basic mechanism for object instantiation within a hibernate Session. Which in turn, raised the following question:

Does using a cache interfere with Hibernate's concurrency (aka, version) features? Does it change which types of concurrency (e.g., version="dirty") are supported?

THanks,

EE

if your app is the only one to update db, cache is ok.
Updated objects via hibernate session are automatically "evicted" from the cache which is filled by the queries...
I may be wrong, hope some cache expert will confirm this

Imagine a web app. 2 users request the same object (same primary key, same table) for editing at about the same time. suppose the pages (via the HttpSession) keep copies of the entities around between requests. 2 different Hibernate Sessions should mean 2 different instances if there is no cache. If there's a cache, however, it might be that both object references (one for each HttpSession) actually refer to the same object. When User A updates it affects User B's object. Then User B updates the same instance and we get "last saved wins" rather than proper concurrency.

At least, without knowing details about EHCache, this is where my own thought process leads me... and hence the concern and the posted question.

Suppose instead that we don't keep instances in the HttpSession, but only Ids (since the normal Hibernate usage seems to discourage dis-connected objects a tiny bit). This breaks concurrency even when there is no cache:

How it should work (nop caching and keeping disconnected objects in the HttpSession):

0. Object X has state "original"
1. User A requests instance
2. User B requests instance gets different instance (different Hib Session, same "original" state)
3. User A sees web page, session keeps Object X.
4. User B sees web page, session keeps Object X(2).
5. User A's edit request: changes made by A are set into X and X is persisted.
6. Object X (in the DB) has state "A's changes".
7. User B's edit request: changes made by B are set into its copy of object X and persistence is attempted. If B changed fields that A also changed the update fails.

How it works if the HttpSession only retains Id and not the instance:

0. Object X has state "original"
1. User A requests instance
2. User B requests instance gets different instance (different Hib Session, same "original" state)
3. User A sees web page, session keeps Object X's ID.
4. User B sees web page, session keeps Object X's ID
5. User A's edit request:
6. Object X is refetched (we only kept around the ID). Changes made by A are set into X and X is persisted.
7. Object X (in the DB) has state "A's changes".
8. User B's edit request:
9. Object X is refetched. Object has state A's changes.
10. Changes made by B are set into the refreshed copy of object X and persisted. If B changed fields that A also changed the update STILL SUCCEEDS since there's no object around (we only hung onto Ids) to inform us of the old state.

Which means that using this approach the App is responsible for concurrency: a fair bit of work...

ehcache with cache="read-write" behaves pretty much as read committed isolation level. I.e. the cache only contains data which has been committed to the DB.

This means that fetching an object from the cache doesn't simply return a reference to the cache object, what happens is that ehcache creates a copy of the cache object and returns a reference to the copy.

So, using ehcache or not should have no implications for transaction isolation of your application if your database is in read committed mode (most db:s are by default). You can use the first option (i.e. keep detached objects in the HttpSession) in exactly the same way regardless if you use ehcache or no cache.

Whoa! What method does it use to make a copy! Does it serialize the object and then desrialize it. My that could be a mighty big object graph. Does it use clone() -- hope not since this will throw and exception (the one thrown by Object's impl) for most of my PoJos. Does it use some fancy memory copying? If so that's a shallow copy. How does the copy method know which of the fields of the copied instance are referring to other objects which might also be in the cache? Do those references now refer to objects actually in the cache's LinkeHashMap?

I'm really curious 'cause my little brain can't think it through in a way that works. How does the cache copy objects?

Of course not.



Of course not.



fancy what?



Read The Source.

OK. But you are still saying it does copying!?