First of all, flushCache() will actually flush the cache.
It will try to passivate the cached instances. Those instances that are in use
(enlisted in transactions) won't be passivated but still will be evicted from the
cache. Nevertheless, the instances remain associated with the transaction and are
scheduled for synchronization at commit, i.e. they will be updated in the database
with changes made in the tx.
What is dangerous and might be a bug is that if you find the flushed instance with the
finder in the same tx, this found instance will be put into the cache (with the data
from the db, i.e. stale data) and associated with the tx. So, there will be two
(different) versions of the same instance and both will be synchronized at transaction
commit. Last commit wins.
You can see it with the following code:
| ALocal a = AUtil.getLocalHome().findByPrimaryKey(new APK(new Long(1),
"avoka"));
| a.setName2("NAME2");
|
| MBeanServer server = MBeanServerLocator.locateJBoss();
| ObjectName container = new ObjectName("jboss.j2ee:service=EJB,jndiName=A");
| server.invoke(container, "flushCache", null, null);
|
| a = AUtil.getLocalHome().findByPrimaryKey(new APK(new Long(1), "avoka"));
| log.info("a.name2: " + a.getName2());
| a.setName2("NAME3");
|
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3839187#3839187
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3839187
-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
