Re: [jbosscache-dev] Pulling the FileCacheLoader from 3.0.0

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.