Bulk deletion of CMP Entity bean

[mfrost]

We have employed a simple cache using CMP entity beans.

We've now identified the need to drop this cache - albeit very infrequently.

We noticed that bulk updates and deletes form part of the EJB3 spec but for now, what is the best mechanism for doing this?

We could write a "findAll" method, iterate over the results and remove(). What are the transactional considerations of doing this? If we have many beans could there be issues with database rollback segments becoming very large?

Effectivley we want to DELETE FROM MY_TABLE and remove all the in memory entities all isolated transactionally from other services that may be currently using the beans.

Anyone faced with a similar problem?

Many thanks in advance.

regard

mark

[gorano]

We are using the data source and make the bulk delete with a normal query.

/G

[aloubyansky]

Keep in mind that with SQL DELETE you could remove some instances that are enlisted in current transactions and these transactions will fail to commit.

[gorano]

It's fine as long as the fields are "out of date" and not in use by the CMPs anymore.

In our scenario we are deleting records older then
1 week. The table is a cache for temporary mapping and we have tuned the CMP cache to expire the records if they are 6 days or older, and the nature of the map is that no lookup will happen after 6 days.

/G

[mfrost]

Would there be any benefit from calling Management Bean method flushCache() on the entity beans EntityContainer?

We've tried this and it causes the beans to passivate. We could the just truncate the table as previously suggested.

Any ideas how this flushCache() might sit with any entity beans that are in use. Could it be dangerous?

Many thanks

mark

[aloubyansky]

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");

[aloubyansky]

I submitted a bug report for this
http://sourceforge.net/tracker/index.php?func=detail&aid=975215&group_id=22866&atid=376685

[mfrost]

Thanks for your comments Alexey - explained a great deal.

regards

mark

[oyabun]

The code Alex provided should be sticky... i searched quite a lot for simple example like this:

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");