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
>>> 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
>>> 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  - 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
Lead, AS Clustering
JBoss, a division of Red Hat