What do you guys think? Too many people try and use this in production and then complain that it doesn't work. It is not transactional and cannot withstand a JVM crash midway during a write. Should we deprecate this in 2.2.0 and remove it in 3.0.0? I know that JBoss AS uses it in some cases, but can that not be changed to use the JDBM cache loader?

Cheers, -- Manik Surtani Lead, JBoss Cache manik(a)jboss.org _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev

On 27 Mar 2008, at 20:17, Brian Stansberry wrote: > Manik Surtani wrote: >> What do you guys think? Too many people try and use this in >> production and then complain that it doesn't work. It is not >> transactional and cannot withstand a JVM crash midway during a write. >> Should we deprecate this in 2.2.0 and remove it in 3.0.0? >> I know that JBoss AS uses it in some cases, but can that not be >> changed to use the JDBM cache loader? > > No, it can't. :( Unfortunately, JDBM appears to be a pretty dead project. "Mature", as some may call it. :-) I was just having a conversation with the JDBM lead the other day - it's certainly not abandoned or anything.

> FCL is just an impl of a pluggable interface though. If you don't want > it in 3.0 and if we can't find a valid replacement by the time AS is > ready to consume 3.0, then I can always pull the FCL code into the > AS/EJB3 source tree. That is always an option, I guess. Shall we stick with deprecating it in 2.2 and removing it in 3.0 then?

Cheers -- Manik Surtani Lead, JBoss Cache manik(a)jboss.org

Manik Surtani wrote: > What do you guys think? Too many people try and use this in > production and then complain that it doesn't work. It is not > transactional and cannot withstand a JVM crash midway during a write. > > Should we deprecate this in 2.2.0 and remove it in 3.0.0? > > I know that JBoss AS uses it in some cases, but can that not be > changed to use the JDBM cache loader? > No, it can't. :( Unfortunately, JDBM appears to be a pretty dead project. FCL is just an impl of a pluggable interface though. If you don't want it in 3.0 and if we can't find a valid replacement by the time AS is ready to consume 3.0, then I can always pull the FCL code into the AS/EJB3 source tree. > Cheers, > -- > Manik Surtani > Lead, JBoss Cache > manik(a)jboss.org > > > > > > > _______________________________________________ > jbosscache-dev mailing list > jbosscache-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosscache-dev

OK, if it doesn't belong in the AS, then JBC has to provide a reliable alternative, one that's not @Experimental and not based-on-a-project-that's-last-release-was-1.0-in August-2005. :) The AS need to reliably passivate sessions is real. Bela Ban wrote: > -1. I don't see what FCL has to do in the AS... > > Brian Stansberry wrote: >> Manik Surtani wrote: >>> What do you guys think? Too many people try and use this in >>> production and then complain that it doesn't work. It is not >>> transactional and cannot withstand a JVM crash midway during a write. >>> >>> Should we deprecate this in 2.2.0 and remove it in 3.0.0? >>> >>> I know that JBoss AS uses it in some cases, but can that not be >>> changed to use the JDBM cache loader? >>> >> >> No, it can't. :( Unfortunately, JDBM appears to be a pretty dead >> project. >> >> FCL is just an impl of a pluggable interface though. If you don't >> want it in 3.0 and if we can't find a valid replacement by the time >> AS is ready to consume 3.0, then I can always pull the FCL code into >> the AS/EJB3 source tree. >> >>> Cheers, >>> -- >>> Manik Surtani >>> Lead, JBoss Cache >>> manik(a)jboss.org >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> jbosscache-dev mailing list >>> jbosscache-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev >> >

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(a)jboss.org

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... -- Manik Surtani Lead, JBoss Cache manik(a)jboss.org

On 1 Apr 2008, at 16:38, Brian Stansberry wrote: >> >> 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. Unless I'm mistaken, the FileChannel lock won't do that either?

-- Manik Surtani Lead, JBoss Cache manik(a)jboss.org