There are several caching options in TopLink Essentials to handle stale data.
These can be accessed through persistence.xml properties or through the
TopLink ClassDescriptor API through a DescriptorCustomizer.
Isolated cache (shared=false) : Allows the shared cache to be turned off for
a class. ("toplink.cache.shared.<class>",
ClassDesctiptor.setIsIsolated(boolean)).
Always refresh : Any query that accesses the database will refresh the cache
objects. (ClassDescriptor.alwaysRefreshCache()). (this not NOT include
queries that get a cache hit).
Only refresh if newer version : Makes use of the optimistic lock version
field to avoid refreshing the cache if the version is the same.
(ClassDescriptor.onlyRefreshIfNewerVersion) need to set this AND refresh).
Disable cache hits : Disables all cache hits (better to use an isolated
cache instead). (ClassDescriptor.disableCacheHits()). (need to set this AND
refresh).
You can also set the cache size and type. ("toplink.cache.type.<class>",
"toplink.cache.size.<class>").
You can also access the TopLink cache through the EntityManager API and
explicitly invalidate objects.
i.e.
((oracle.toplink.essentials.ejb.cmp3.EntityManager)entityManager.getDelegate()).getServerSession().getIdentityMapAccessor().invalidateClass(<class>);
In TopLink 11g (preview), and EclipseLink (incubation) there are also
several other caching options, including cache invalidation, and cache
coordination.
In terms of performance for bulk updates or deletes you can also consider
using the JPA update-all, delete-all queries. These allow you to make large
updates using JPQL and have optimal performance and ensure the cache is
maintained.
See also,
http://wiki.glassfish.java.net/Wiki.jsp?page=Caching,
http://en.wikibooks.org/wiki/Java_Persistence/Caching,
http://en.wikibooks.org/wiki/Java_Persistence/Locking
Witold Szczerba wrote:
>
> Hello there,
> I have a question about how does JPA handle changes in tables made by
> database triggers or other JDBC connections (from within the same EJB
> module of course).
>
> If I change database record using JDBC and then I invoke
> em.find(Something.class, someID), will TopLink figure out that
> something changed? Or will I get stale data?
>
> If I use @Version fields, are they going to help? For example, JPA
> could check if version changed and reload entity automatically.
>
> I am asking, because I have application that is using JPA, but JPA is
> really bad for massive data modifications. In my case, I have few
> services like the one that has to update about 20.000 records -
> calculation of interest on every active loan. The result of that will
> create Transaction entities, AccountEntry entities, it has to update
> loan's checkDate/status property generate proper Actions, check
> Actions generated before to insert or update Tasks...etc...)
>
> With JDBC, very similar operations can be done in seconds, but using
> JPA that would last for ever because of thousands of separate selects,
> huge memory footprint...
>
> I am just worried, if I implement this using DataSource bypassing
> EntityManager, will I desynchronize EM cache with database? That would
> lead to disaster :/
>
> Thanks,
> Witold Szczerba
>
-----
---
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.oracle.com/technology/products/ias/toplink/ Oracle TopLink ,
http://www.eclipse.org/eclipselink/
EclipseLink , https://glassfish.dev.java.net/javaee5/persistence/ TopLink
Essentials
Wiki: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence ,
http://wiki.eclipse.org/EclipseLink EclipseLink
Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink ,
http://www.nabble.com/java.net---glassfish-persistence-f13455.html Glassfish
Persistence
--
View this message in context: http://www.nabble.com/JPA-%2B-database-triggers-or-other-non-JPA-db-manipulation-tf4618195.html#a13214089
Sent from the java.net - glassfish users mailing list archive at Nabble.com.