Have you tried the cache invalidation service?
Juha, thank you very much for the reply.
After reading the chapter on Cache Invalidation in the JBossClustering document, my understanding was that you can only invalidate by indicating specific entity keys and their invalidation group (batchInvalidate()). It doesn't say anything about being able to invalidate the complete cache with one command/switch. Pls let me know if I am missing something.
you can manually invalidate the entire cache through the jmx-console - you have to navigate to the cache service of the entity bean of interest and click flush().
Because the jmx-console is only a web frontend to the jmx services you can also call the flush action programatically - then you better try for instance a rmi-invoker for jmx and call the flush()-operation of the relevant jmx component.
Manuel, thanks for the solution.
Personally, I prefer using the twiddle utility.
A great little tool that is. You just have to "invoke" the flush method on the cache service of your ejb.
Thanks. I did not know about the "twiddle" before. Will surely try it out.
Will flush() write the contents of the cache to the data store (as the name suggests), or simply invalidate the contents of the cache?
If running in commit option A, perhaps flush() knows that it is in control of the DB and therefore knows that it is in sync with the DB and there would be no need to flush its contents to the DB. If that's the case, then maybe it doesn't bother emptying the contents of the cache either?
This is all guess work as the documentation available for JBoss is dreadful and the forums have little on the topic. I'm afraid that the jboss code may be the best place to find answers.
Your question is really more an issue of understanding EJB and not JBoss specifically.
When using commit option A, the container assumes exclusive "ownership" of the database so it can cache the data very aggresively. However, at no time does the cache contain incomplete writes to the database outside the scope of a transaction. The data in the cache is synchronized with the database and as such, the container can serve data to requesting clients without re-reading from the database.
The flush() command simply invalidates the cache so when a request for that data comes in, the container will re-request the data from the database.
The documentation makes this fairly clear. See this chapter of the on-line docs: http://docs.jboss.org/admin-devel/Chap11.html
Specifically reference Commit Options here: http://docs.jboss.org/admin-devel/Chap11.html#0_pgfId-926545