Re: [jboss-dev] Embedded DB for internal use
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(a)redhat.com