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? regards marcel
