|
Re: Caching Behavior for @ReadOnly Entities? [message #518044 is a reply to message #517594] |
Tue, 02 March 2010 20:43 |
|
Read-only objects are meant to only exist in the shared cache. Using an isolated or not shared cache with read-only would be unusual. If you want the object registered in the unit of work, then just don't mark it as read-only.
To refresh a read-only object execute a query for it using the "eclipselink.refresh"="true" query hint, or using the JPA 2.0 find() that takes query hint properties with the refresh.
You can also invalidate the object in the shared cache using the Session IdentityMapAccessor invalidateObject() API.
James : Wiki : Book : Blog : Twitter
|
|
|
Re: Caching Behavior for @ReadOnly Entities? [message #518048 is a reply to message #518044] |
Tue, 02 March 2010 20:56 |
No real name Messages: 2 Registered: March 2010 |
Junior Member |
|
|
Thanks for the tip. One interesting behavior I noticed while trying to implement your first suggestion was that when I marked my query as REFRESH=True and REFRESH_CASCADE=AllParts my graph traversal slowed to an absolute crawl. This is in contrast to the initial traversal of an uncached graph without those hints, which is reasonably fast. My object model is fairly deep and can contain hundreds of objects, so maybe mine is an exceptional case, but it's odd to me that it's way, way faster to fault an uncached object into memory than it is to execute a cascade refresh. But maybe I'm missing some of the implications of REFRESH_CASCADE.
In any case, simply clearing out the entire secondary cache at the beginning of each UnitOfWork using JPA 2.0 Cache.evictAll() works for my needs, since I know when my volatile read only objects are modified. It's much, much faster than REFRESH_CASCADE, which is kind of unfortunate.
[Updated on: Tue, 02 March 2010 20:57] Report message to a moderator
|
|
|
Powered by
FUDForum. Page generated in 0.02873 seconds