Caching in a long running conversation

[trossmy]

I just discovered that there is a (hidden?) caching mechanism in a long running conversation, in the sense that the result of jpa queries is cached, until the long running conversation is ended...the caching seems to be quite sophisticated in a sense that jpa queries return new records in the database but not updated ones...once the conversation is ended and a new one is started the updated records are fetched... in my persistence.xml I have disabled query and second level caching.
Anybody got a clue of what's going on and what to do?

[asookazian]

Seam-managed persistence context (SMPC) is a conversation-scoped, extended PC.  The PC serves as a 1st level cache (this is what enables us to queue changes to entities and flush them all at the end of the LRC/transaction, thereby minimizing db round trips).  So whenever you load some entities, say via a createQuery() call, those entities are managed by the PC and are in the 1st level cache.

When you end the LRC, the SMPC is destroyed by the Seam container.  Assuming that the PC was flushed (typically via AUTO or MANUAL) prior to the end of the conversation, and the tx was successfully committed, then the CRUD operations queued in the PC are executed from you persistence provider via the JDBC driver to your RDBMDS.

If you want more details on all this, read JPA/Hibernate or SiA books.

Check out this class in the core Seam codebase if you want to know how it works (you can add debug brkpts to see what is happening when): org.jboss.seam.persistence.ManagedPersistenceContext

[asookazian]

Also, the Yuan 2nd ed. Seam book has a very good section on caching strategies (1st and 2nd level).

[asookazian]

This is a very good article on L1 and L2 caching in JPA 2.0:

http://weblogs.java.net/blog/caroljmcdonald/archive/2009/08/jpa_caching.html

[asookazian]

Another very good one on MySQL: http://blogs.sun.com/carolmcdonald/entry/mysql_for_developers

[trossmy]

thanks Arbi for the detailed answer...does that mean I have to give up the idea of having updated entities while the LRC is still alive?

[trossmy]

So, as far as I understand the entities are cached in the first-level cache, which is the persistence context. So before I execute the query I can call entityManager.clear, and I get fresh entities. But then all entities in the LRC are detached, right? And I might run into lazy initialization exceptions?

[trossmy]

anyway, calling entityManager.clear before executing the query seems to be the solution for my app...haven't run into any problems so far.