[jbosscache-dev] Pulling the FileCacheLoader from 3.0.0

[Brian Stansberry]

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