Re: [jbosscache-dev] Pulling the FileCacheLoader from 3.0.0
Manik Surtani wrote:
On 28 Mar 2008, at 16:13, Brian Stansberry wrote:
> Bit of a tangent on whether something like FCL belongs in JBC or in
> outside.
>
> 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
> requirements:
>
> 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.
Good point.
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.
The AS usages have some code meant to deal with this (although how good
it is I won't comment.) The current usage actually doesn't even allow
reads from the local FCL after restart -- regions are purged. The
session FCL isn't really a "persistent" store in the typical sense.
It's an out-of-process memory overflow area. The cluster itself is meant
to be the reliable store.
> 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 impl.
>
>
> All this said, I'd *much* prefer a good solution that ships with JBC. :-)
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.
Sure. My comment above about "out-of-process memory overflow area" also
made me realize a value FCL has vs. any embedded DB based approach. The
FCL persistent store is really "out-of-process memory." With an
embedded DB cache loader, if I evict something, who knows if/when I'm
really freeing memory. Depends on how the DB caches stuff.
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?
Yes. I think Elias proposed something along that line as well. Perhaps
some use of the java.nio.FileChannel lock stuff too.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com