CacheLoader bug - JBCACHE-352

[manik]

See http://jira.jboss.com/jira/browse/JBCACHE-352 for an explanation of the bug and consequences.

What do people think of this? Is this a common problem, have customers complained about this iin the past? Just trying to gauge priority in fixing this.

- Manik

[brian.stansberry]

Is the cache loader backed by a database?

If so, I'd expect the remove would propagate to the loader, and thus to the db. The subsequent get would not find anything in the db, as the call is part of the same tx.

If the above analysis is correct, then this issue would be limited to loaders backed by a non-transactional persistent store. We don't recommend FileCacheLoader for production use.

[manik]

The thing is, CRUD methods are not executed on the CacheLoader implementation until commit time. So even if your DB store supported transactions, the remove will not make it down to the DB until you do a commit (happens in the prepare phase, actually)

So you still have the problem.

The fix - and in my opinion the correct way to do this - would be to directly call gets and removes on the cache loader when they happen even if you are running in a tx. Then then the cache loader impl can decide if it needs to maintain a list of mods or use an underlying tx mechanism (e.g., DB transactions, BDB transactions).

The problem is, this fix will mean a change in the semantics of cache loaders and in addition to patching existing cache loaders, will break a bunch of custom cache loaders people have written.

Any other ideas on how to achieve this, though?

Cheers,
Manik