|
|
Re: JMS cache coordination on GlassFish cluster [message #1062081 is a reply to message #1062045] |
Wed, 05 June 2013 19:03 |
Chris Delahunt Messages: 1389 Registered: July 2009 |
Senior Member |
|
|
The clear call forces EclipseLink to drop all managed entities and the changesets associated to the transaction so far, so there is nothing to merge into the local cache let alone remote caches when it completes. What does is track the classes that were touched if there were flushed changes, and when it commits, these classes are invalidated locally - this is configurable through the "eclipselink.flush-clear.cache" property which defaults to FlushClearCache.DropInvalidate. It looks like you can file a feature request/bug to have these class invalidations sent to remote servers.
The workaround would be to set the "eclipselink.flush-clear.cache" property to "merge" instead, which will cause the clear to still keep the cumulative changeset for merges and send them to remote servers. It has a bit larger memory foot print, but still allows the managed entities to be garbage collected.
A different workaround might be to send a RCM command to all servers to evictAll on the remote caches as well since you are already calling em.getEntityManagerFactory().getCache().evictAll(); locally. This might involve creating a org.eclipse.persistence.sessions.coordination.Command implementation that on executeWithSession calls session.getIdentityMapAccessor().invalidateAll(); This might only be useful if this is not a regular occurrence, as it can be a lot of work to maintain the cache and send changes around which gets wasted if you are wiping it out frequently. In which case, you might turn off the shared cache by using isolated session caches instead, avoiding the need for JMS cache coordination.
Best Regards,
Chris
|
|
|
|
Powered by
FUDForum. Page generated in 0.17459 seconds