On 28 Mar 2008, at 16:13, Brian Stansberry wrote:
Bit of a tangent on whether something like FCL belongs in JBC or in
JBC rightly wants any CacheLoader impl it ships to be able to handle
the full spectrum of CacheLoader use cases. AIUI, this is the
primary objection to FCL -- it can't.
The AS session passivation needs a CL impl that only meets these
1) No user intervention to set up (i.e. no creating tables for in
Oracle for JDBCCacheLoader)
2) Support passivation=true. No need for transactional writes.
It's not just transactional writes. Imagine a scenario where a non-
transactional put() in the cache results in a FCL write. And the JVM
crashes during the write. Instant corrupted data on restart. The
reason why other CLs are resilient to this is because of transactions
- where even a non-transactional cache put() results in the CL
starting a tx, doing a write, and committing the tx. Note though that
these won't necessarily be JTA txs but library-specific txs, like
BDBJE txs or JDBM txs.
So I'd think that FCL usage in the AS could be risky as well, even
though you don't use transactions for cache puts.
3) Supports shared=false
4) Adding docs saying "if you want to put $JBOSS_HOME/server/all/
data on an NFS, we recommend a switch to JDBCCacheLoader" is not
lovely but acceptable.
So, conceptually there's a disconnect between JBC's requirements and
the AS's. Seems like thats one of the reasons a project provides a
pluggable API -- to let people who need one use a custom-tailored
All this said, I'd *much* prefer a good solution that ships with
Agreed - I too think a good, very easy to use filesystem based cache
loader that ships with JBC is a good thing. But it needs to be
generally usable for a wide variety of use cases.
Perhaps the correct approach is to "fix" the FCL? E.g., when doing
writes, copy the original file to a .old file, do the write, and then
delete the .old file. In the event of a corrupted read, look for
a .old file and perform a cleanup?
Lead, JBoss Cache