jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Excerpts Question
Date Tue, 17 Jun 2008 07:52:48 GMT
Marc Schriftman wrote:
> At the moment, I'm more concerned about BundleFsPersistenceManager. I'm
> stuck with it for now - are you aware of anything I need to particularly
> watch out for, or any precautions I can take to safeguard it?

using the data store feature might lower the risk of an inconsistency because 
larger binary properties are not stored through the persistence manager. this 
will lead to smaller transactions, thus lowering the risk that Jackrabbit can 
crash during that time.

> Is there any
> plan to transactionalize it in the future?

Not that I know of.

> Is it even possible to
> transactionalize a FS-based PM? I'm guessing that if it were easy to do, it
> would have been done already...

It would mean to keep track of changes that are written during a commit and 
provide a facility that can rollback changes when a commit fails or an 
uncommitted transaction is detected on startup.

> The reason I chose BundleFsPersistenceManager in the first place was because
> I must be able to persist the entire repository to a remote device (via a
> custom FS) and if I'm not mistaken, BundleDbPersistenceManager makes use of
> a combination of configured FS and local storage. Is there another option?

The BundleDbPersistenceManager is pretty much the recommended configuration. 
Whether binary properties are written to the database as well or to a file 
system can be configured. As of 1.4.x we also recommend to use the data store 
for binary properties. The data store writes binaries to a file system or 
alternatively to a database (though I'm not sure if that's already in 1.4.x).

Why do you need to store the content on a remote device?


View raw message