Eclipse Community Forums: EclipseLink » Caching Behavior for @ReadOnly Entities?

Home » Eclipse Projects » EclipseLink » Caching Behavior for @ReadOnly Entities?

Caching Behavior for @ReadOnly Entities? [message #517594]

Mon, 01 March 2010 08:14

Eclipse User

Hey folks,

I've got a number of entities tagged as @ReadOnly, and I can't seem to
control when they refresh their state from the database, either manually or
through cache configuration. My ideal would be one of these two options:

1) Configure the cache so the state of a @ReadOnly entity is preserved for
the duration of a single UnitOfWork.
2) Be able to manually refresh the state of a @ReadOnly entity.

I've tried various ways to accomplish #1 (Even setting CacheType to NONE as
an experiment) and EclipseLink doesn't seem to care. The documentation is
sparse on the intersection of @Cache and @ReadOnly, though, so hopefully I'm
just missing something.

There isn't an obvious way to get at #2 either. @ReadOnly entities are
detached, so calling EntityManager.refresh() just causes an exception.

Anybody have any advice for me?

Thanks,
Ryan

Re: Caching Behavior for @ReadOnly Entities? [message #518044 is a reply to message #517594]

Tue, 02 March 2010 15:43

Eclipse User

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.

Re: Caching Behavior for @ReadOnly Entities? [message #518048 is a reply to message #518044]

Tue, 02 March 2010 15:56

Eclipse User

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 15:57] by Moderator

Previous Topic:	preUpdateWithChanges
Next Topic:	How to obtain connection from EntityManagerFactory?

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 22 18:08:05 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter