[jbosscache-dev] Pulling the FileCacheLoader from 3.0.0
Brian Stansberry
brian.stansberry at redhat.com
Mon Mar 31 15:03:01 EDT 2008
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 at jboss.org
>
>
>
>
>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com
More information about the jbosscache-dev
mailing list