|
Re: CACHE_TYPE_DEFAULT [message #383012 is a reply to message #383007] |
Thu, 06 November 2008 14:17 |
|
clear() only clears the transactional cache, not the shared cache. To
refresh an object in the shared cache you need to call
EntityManager.refresh() with the object.
You can also set the "eclipselink.refresh"="true" query hint on any query.
I would not recommend using CacheType.None, if you truly do not which to
cache, you can use an isolated cache using the persistence.xml property
"eclipselink.cache.shared.default"="false".
If you want to manually clear the shared cache use can get the EclipseLink
Session (getServerSession()) from the EclipseLink JpaEntityManager, and
get the IdentityMapAccessor (getIdentityMapAccessor()) from the Session.
The IdentityMapAccessor contains API to clear and invalidate the cache.
On a live system invalidation is safer than clearing, as the objects may
be in use (initializeIdentityMaps(), invalidateAll()).
----
James
http://www.nabble.com/EclipseLink---Users-f26658.html
James : Wiki : Book : Blog : Twitter
|
|
|
Re: CACHE_TYPE_DEFAULT [message #383013 is a reply to message #383012] |
Mon, 10 November 2008 10:09 |
Tom Eugelink Messages: 817 Registered: July 2009 |
Senior Member |
|
|
> clear() only clears the transactional cache, not the shared cache.
Understood.
> I would not recommend using CacheType.None, if you truly do not which to
> cache, you can use an isolated cache using the persistence.xml property
> "eclipselink.cache.shared.default"="false".
Ok. My application is a change-heavy application; orders are entered, articles get a different status, data is changed all the time. The users know that other users may also change data, but they really need to be certain that when a refresh is done, they really have the most current data. Caching is only ok during a session (that is: work done not inside a transaction). As soon as a transaction has run, and the changes have been committed, data needs to be refreshed.
I'm a bit amazed that the cache is this cachy; as in that one has to explicitly refresh stuff. This model seems to work for webapps (many EM but all running within one JVM) and not a simple 2 tier fat client (just a few EM per JVM but multiple JVMs).
Hmmm. Maybe I should consider a distributed cache. That would solve the "has been updated" issue.
> If you want to manually clear the shared cache use can get the
> EclipseLink Session (getServerSession()) from the EclipseLink
> JpaEntityManager, and get the IdentityMapAccessor
> (getIdentityMapAccessor()) from the Session. The IdentityMapAccessor
> contains API to clear and invalidate the cache. On a live system
> invalidation is safer than clearing, as the objects may be in use
> (initializeIdentityMaps(), invalidateAll()).
Thanks for the complete reply!
Tom
|
|
|
|
Re: CACHE_TYPE_DEFAULT [message #500957 is a reply to message #383015] |
Mon, 30 November 2009 13:18 |
Tom Eugelink Messages: 817 Registered: July 2009 |
Senior Member |
|
|
Revisting the caching because I'm running into some performance issues during data entry in my Swing application.
Is it very strange that I expect entities to be cached within an EM, until the EM is cleared?
public static void main(String[] args)
{
System.out.println( "java.vm.version=" + System.getProperty("java.vm.version"));
com.informix.jdbc.Version.main(new String[]{});
// -------------
// entitymanagerfactory
Map<String, Object> lOptions = new HashMap<String, Object>();
lOptions.put(PersistenceUnitProperties.JDBC_DRIVER, ...);
lOptions.put(PersistenceUnitProperties.JDBC_URL, ...);
lOptions.put(PersistenceUnitProperties.JDBC_USER, "user");
lOptions.put(PersistenceUnitProperties.JDBC_PASSWORD, "user");
lOptions.put(PersistenceUnitProperties.TARGET_DATABASE, nl.reinders.jdbc.InformixPlatform.class.getName());
lOptions.put(PersistenceUnitProperties.TARGET_SERVER, TargetServer.None);
EntityManagerFactory lEntityManagerFactory = Persistence.createEntityManagerFactory("reinders", lOptions);
// entitymanager
EntityManager lEntityManager = lEntityManagerFactory.createEntityManager();
// test
lEntityManager.createQuery("select t from Relation t where t.iRelationnr=1").getSingleResult(); // expect: not cached
lEntityManager.createQuery("select t from Relation t where t.iRelationnr=1").getSingleResult(); // expect: cached
lEntityManager.clear();
lEntityManager.createQuery("select t from Relation t where t.iRelationnr=1").getSingleResult(); // expect: not cached
// close shop
lEntityManager.close();
lEntityManagerFactory.close();
}
|
|
|
Re: CACHE_TYPE_DEFAULT [message #500968 is a reply to message #383007] |
Mon, 30 November 2009 14:14 |
|
Yes, all objects read through an EntityManager will be cached locally until the EntityManager is cleared, or until the end of a transaction if using a JTA container managed EntityManager.
However, by default only the find() operation will obtain a cache hit by primary key. A JPQL query will not obtain a cache hit by default, unless the query hint "eclipselink.cache-usage"="CheckCacheByPrimaryKey ", or "eclipselink.query-type"="ReadObject" are set.
JPQL queries will still get a cache hit after accessing the database, so the object and its relationships will not be rebuilt, and object identity will be preserved.
James : Wiki : Book : Blog : Twitter
|
|
|
|
Re: CACHE_TYPE_DEFAULT [message #501720 is a reply to message #383007] |
Thu, 03 December 2009 15:29 |
|
Setting the cache-usage property is fine for an Query that returns a single object (getSingleObject()). But will not work will queries that return multiple objects (getResultList()), as you would only get a single object.
James : Wiki : Book : Blog : Twitter
|
|
|
|
Powered by
FUDForum. Page generated in 0.04200 seconds