flushCache issue

[aloubyansky]

I would like to share some thoughts while I am working on the fix for http://jira.jboss.com/jira/browse/JBAS-979

If an instance is in use in a transaction, it cannot be just removed from the cache.
Because subsequent invocations in the same tx will reload the (maybe updated) data from the database which will break isolation. In fact, this is the case currently.

Flush could be modified to evict only instances that can be passivated (i.e. instances that are not in use). While it would fix synchronization issue described in the report, this is not enough. It breaks consistency. Imagine, an instance is in use, someone modifies data in the db, executes flush, the tx updates the data and commits. Consistency is broken.

So, it seems like the instance in use after flushCache() should be kept in the cache until the transaction that is using it commits. And then it should be evicted. Also, if the transaction modified the instance, the update should fail. Now, it actually becomes an optimistic semantic...
Another way would be instead of keeping the instance in the global cache, keep it in a transaction local cache. But that seems to be more complicated in implimentation...

[aloubyansky]

I am going to apply the following changes as a fix:

- flushCache() is going to evict only instances that currently are not in use, leaving instances in use in the cache until the transaction commits.

- add a new element to the container-configuration: store-not-flushed. The value of the element indicates whether dirty instances that could not be evicted from the cache after flushCache() should or should not (to prevent potential data inconsistency) be stored at sync time. The default value is true (the way it has worked until this moment). Setting it to false will result in an EJBException at sync time for modified instances (note: this doesn't affect not modified instances and the invocation of ejbStore on them).

Note, the changes affect not only flushCache (which can be called programatically, by option-D-refresh thread or cache invalidation manager) but also time-based eviction policy.

[aloubyansky]

The issue has been fixed.
Testcase: org.jboss.test.cmp2.jbas979.JBAS979UniTestCase
Wiki: http://wiki.jboss.org/wiki/Wiki.jsp?page=CMPFlushAgeOutStoreNotFlushed