|Shared cache returning same object (identity) to different sessions? [message #817557]
||Sat, 10 March 2012 08:33
| Davy Herben
Registered: March 2012
I'm building a JEE6 application with eclipselink JPA2 on glassfish 3.1.1, and I'm puzzled by some behaviour I'm seeing that seems to be related to the shared session cache.
The application, for now, is a simple crud application for a list of Product entities. All is going fine with one user, but when testing with multiple users, I noticed that changes to a Product by user A were immediately visible to user B, even though user A had not committed anything yet, and nothing was written to the database.
After a lot of debugging, I found out that both users, from their respective EntityManagers, were receiving the exact same object, which of course explains the behaviour I've seen. After completely disabling the shared cache, the problem went away, but so did the performance of the application.
Is it normal that the EclipseLink shared cache is returning the same object to different users? I could see how this could make sense for objects that are marked as read-only. You're not supposed to change those, so it would not hurt to share object identity among user sessions. But I cannot see this making any sense for read-write objects. That probably means I'm either doing or thinking something wrong.
I do want Product instances to be cached in the shared cache, no need to go to the database every time. I would expect the cache to return me a clone of the cached object though, not the cached object itself.
In case it matters: the application is following Adam Bien's Gateway pattern: the entities are retrieved from an EXTENDED EntityManager, and not inside a transaction. A transaction is only started to commit the changes. This keeps the objects attached across user requests. I've been thinking that maybe the nontransactional loading makes EclipseLink consider the entities as read-only?
Any help or insight would be much appreciated.
Powered by FUDForum
. Page generated in 0.01868 seconds