Documenting Limitations of FileCacheLoader

[brian.stansberry]

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?

[galder.zamarreno]

+1

I think it should go on documentation as this information is crucial for the
customer to be able to make the decision on which CL to use and be aware of
the limitations.

Looking back on people's past experience, I think FLC does not perform well
when handling big trees.

Also, The use of a FileCacheLoader over a shared filesystem by NFS is bad;
concurrent access to the file cannot be prevented, therefore you are likely to
experience inconsistencies caused by concurrent updates to the same file.
Even if I added file locks, some NFS implementations might even ignore the
lock requests altogether... ( thanks Bela :-) )

[manik]

Not just NFS, but most shared file systems including SMB do not have a proper notion of file locks (perhaps RHAT's GFS may be different).

And Galder is right, FCL is not performant for large trees since this involves directory traversal, but then again I'm sure this depends on the file system used (ext3 vs reiserfs vs Windows NTFS, etc).

To be honest, I tend to recommend not using this at all in production. I think a much better bet would be the JDBM cache loader, which is pretty poorly documented at the moment.

[galder.zamarreno]

I only realised JDBM couple of days ago when I was comparing 1.3.x to 1.4.x.
At least it's transactional which is already better than FCL.

Manik, did you code the JDBM CL? what other differences/bonuses did you
find compared to FCL?

[brian.stansberry]

Elias Ross (aka genman) submitted it.

There's a comment in JdbmCacheLoader javadoc: "Does not support transaction isolation."

"Manik Surtani" wrote:
To be honest, I tend to recommend not using this at all in production. I think a much better bet would be the JDBM cache loader, which is pretty poorly documented at the moment.

Hmm. The default passivation cache for EJB3 SFSBs and HttpSessions (Hany's work) both use FCL. Some other options:

1) Use JDBCCacheLoader working off of DefaultDS. We of course recommend using a production DB to replace Hypersonic; this becomes another reason to do this. And now that production db needs to have the appropriate tables or let JDBCCacheLoader create them.

2) Use JdbmCacheLoader. Now we've got another embedded db.

[ben.wang]

I'd say either JDBCCacheLoader (or even the SleepyCat BdbjeCacheLoader, although it may not be well tested) for production usage. As Brian mentioned, this is aligned with our AS recommendation.

[manik]

Hmm, wouldn't JDBM perform a lot better than a JDBC cache loader, even if it is backed by a local DB like Hypersonic?

I agree about the consistency wrt. the JDBC cache loader though.