[jbosscache-dev] Pulling the FileCacheLoader from 3.0.0

[Manik Surtani]

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.

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

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.

[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