[jbosscache-dev] Pulling the FileCacheLoader from 3.0.0

[Brian Stansberry]

Manik Surtani wrote:
> 
> On 31 Mar 2008, at 20:03, Brian Stansberry wrote:
>> 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.
> 
> Fair enough; that makes sense then, but I would categorise this as a 
> *very special* CL implementation that relies on application (AS) 
> specific behaviour (purging regions on restart) to prevent data 
> corruption.  Not generic at all then, since using the FCL as it is right 
> now for any other purpose will introduce the possibility of corrupt data.
> 

Yeah, pretty specialized. You can see where the disconnect comes from; 
it works for my specialized usage so having it be called 
not-production-ready is a bit of a bummer.

That said, I'd like to have flexibility to get rid of the purging 
regions on restart.  There are currently other reasons for it than the 
data corruption issue though.

>>>> 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.
> 
> I guess the point is, is it worth fixing and then supporting?  Or are we 
> better off pulling it from the distro and having AS implement it for 
> it's "specialised" use case?  If it can be fixed effectively, then I'd 
> prefer that approach.
> 

Me too. I think it's worth fixing.  See my comment above re: memory 
overflow and cache loaders based on an embedded DB.  FCL is a simple CL 
that for sure keeps nothing in memory, so meets a need.

> Re: FileChannel, locking is less important since I have implemented 
> locking on a per-Fqn basis in the FCL [1] - agreed the FileChannel stuff 
> may be better, but it's a less urgent need since locking isn't a problem 
> with the FCL anymore.
> 

If the FCL is used with a shared=true you need to coordinate access to 
the filesystem.

> [1] 
> https://svn.jboss.org/repos/jbosscache/core/trunk/src/main/java/org/jboss/cache/loader/FileCacheLoader.java 
> 
> -- 
> 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