[jboss-dev-forums] [Design of JBossCache] - Documenting Limitations of FileCacheLoader

bstansberry@jboss.com do-not-reply at jboss.com
Mon Oct 16 09:42:55 EDT 2006


Discussion thread for http://jira.jboss.com/jira/browse/JBCACHE-807

I'll do this, but would like input from others on the specific issues with FCL, and in what, if any, use cases it's production use is acceptable.

My understanding of the problem with FCL is that the filesystem is not a transactional resource and FCL only makes a small attempt to deal with this (by writing transaction-scoped changes during the commit phase rather than prepare.)  This would be an issue if there is some problem writing the changes. 

It also basically means that only READ_COMMITTED semantics are possible at the cache loader level; enforcing other semantics requires interaction with the cache's node locking (e.g if a node is read from the filesystem in a tx, an RL is held on the resulting cache load, preventing a write from another thread, hence REPEATABLE_READ.)

A potential added problem could be related to locking if the cache is configured with isolation level NONE such that multiple threads could simultaneously get a WL on a node and therefore simultaneously write to the same file.

Re: uses cases, these limitations are mitigated somewhat if the use case is one where only a single thread should be accessing a given Fqn at any time.  For example, possibly session management with sticky sessions.  But, consideration needs to be given to factors like any background thread doing eviction.

Comments?


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978537#3978537

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978537



More information about the jboss-dev-forums mailing list