On 4/21/06, LoïcPéron <[EMAIL PROTECTED]> wrote:
Hi,

I intend to use Jackrabbit as a JCA-enabled JCR content repository in a J2EE
application. I will have large blobs to store. I need distributed transactional
behaviour to ensure consisytency with other systems. I also need recovery
insurance in case of failure. My blobs should be stored on a file system.

Some searches on this list seem to indicate that Jackrabbit is _not_
transactional when using a file system base persistence manager. Does Jackrabbit
delegate transactionality to the database?

no, jackrabbit doesn't delegate transactionality to the database.

jackrabbit's transaction support requires that changes are stored
atomically on the persistence layer. see PersistenceManager#store(ChangeLog).

the jdbc-based pm's make use of db transactions to guarantee that changes are
stored atomically.

file-system based pm's would need a transactional FileSystem to accomplish
this. there's currently no FileSystem implementation in jackrabbit supporting
transactions.

also note that if you're using a jdbc-based pm that's confgured to store blobs
in the file system rather than in the database (i.e. externalBlobs=true)
your setup is not fully 'transactional' for the same reasons as stated above.


If I need to use a database to benefit from transactional behaviour, may I use
Derby as a local database and store my large blogs (up to 10Gb) in it?

in general, yes. but you may want to do some research if derby supports
blobs of 10gb size... you would also have to tweak derby's schema.


If I need to store my blobs externally to the database due to their size, will
the  file system based blob storage benefit from tansactional behaviour too?

no, see above.

cheers
stefan


Last but not least, what is required to be sure my repository will always be
able to recover from a crash, particularly given my file system storage
constraints?

Thanks to all for your hard work.



Reply via email to