Basically avoids issues with FileCacheLoader, which the JBC
team doesn't
recommend using in production.[1]
Some specific stuff I've seen:
1) Had to add a dummy level w/ 100 nodes in it to the Fqns
we use for
storing sessions. Otherwise we were hitting file system
limitations on
the # of subdirectories you could have under a directory,
limiting the
max number of beans.
2) On Windows with FIELD granularity web sessions, the
directory
structure gets deep enough that I'm starting to see maximum
file path
length issues in unit tests. (This is the one that prompted
my post.)
[1] From the Section 8.3.1 of the JBC docs:
"The FileCacheLoader has some severe limitations which
restrict it's use
in a production environment, or if used in such an
environment, it
should be used with due care and sufficient understanding of
these
limitations.
* Due to the way the FileCacheLoader represents a tree
structure on
disk (directories and files) traversal is inefficient for
deep trees.
* Usage on shared filesystems like NFS, Windows shares,
etc. should
be avoided as these do not implement proper file locking and
can cause
data corruption.
* Usage with an isolation level of NONE can cause
corrupt writes as
multiple threads attempt to write to the same file.
* File systems are inherently not transactional, so
when attempting
to use your cache in a transactional context, failures when
writing to
the file (which happens during the commit phase) cannot be
recovered.
As a rule of thumb, it is recommended that the
FileCacheLoader not be
used in a highly concurrent, transactional or stressful
environment, and
it's use is restricted to testing. "
Bill Burke wrote:
> what benefit does a DB give you?
>
> Brian Stansberry wrote:
>> I know there've been a few threads on this general
topic, so please
>> forgive if I'm rehashing old ground.
>>
>> I'd like to replace the way clustered web sessions
and clustered EJB3
>> SFSBs store their data. They currently do it to
the file system via
>> JBossCache's FileCacheLoader. Lot's of issues with
that. A simple
>> alternative is a config change to use
JDBCCacheLoader and have the
>> storage done to an embedded DB.
>>
>> My assumptions about this are:
>>
>> 1) Each AS instance would be *meant to* have it's
own DB instance;
>> it's not meant to be a shared resource. A user
reconfiguring the AS to
>> share the same db instance with the same schema
between AS instances
>> would be making a configuration mistake.
>> 2) It would be a production ready RDBMS (Derby
???); expectation would
>> not be that customers should replace it by
default.
>> 3) We'd deploy our own datasource (say
"EmbeddedDS" or "InternalDS")
>> to talk to it. Internal services like I described
would use that
>> datasource.
>> 4) DefaultDS could point to it as well, so the AS
works out of the
>> box. But the recommendation there would be the same
as now --
>> reconfigure the DefaultDS to point to an external
production-ready DB.
>>
>> Thoughts?
>>
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry redhat.com
_______________________________________________
jboss-development mailing list
jboss-developmentlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
|