[jbosscache-dev] Pulling the FileCacheLoader from 3.0.0

[Manik Surtani]

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.

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  
> 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.

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?

Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org