Edgar Poce wrote:
IMHO ...
FileSystems
- LocalFileSystem . Slow on window boxes . non transactional . If the jvm process is killed the repository might turn inconsistent . easy to configure
- CQFS file system . fast . non transactional . if the jvm process is killed the repository might turn inconsistent . easy to configure . license issue
- VFS
. not an option
. I think the vfs team will add transaction support. If this happens, a cqfs provider for vfs will be an interesting option.
----- PersistenceManagers
ObjectPersistenceManager . simple . Not human readable . An inconsistency is hard to fix without a tool . easy to configure . Write operations are synchronized
XMLPersistenceManager . not so simple but human readable . easy to configure . Write operations are synchronized
OJBPersistenceManager . Unnecessary complexity . transactional . rdbm referencial integrity . not so easy to configure. . Multithreaded friendly. Write operations don't need to be synchronized.
HibernatePersistenceManager
. Need some work, the JCR-63 issue is closed but the problems are still there.
. not so easy to configure
I'm currently working on "porting" your OJB changes to the HibernatePersistanceManager, by also using the store(ChangeLog). But I'm still seeing quite a lot of test failures. Maybe I should put the code somewhere in case somebody wants to help out ?
Also I would add to your list of features the persistence managers that are cluster friendly. Shared filesystems are not trivial to setup properly, whereas share databases are quite trivial. Somehow I don't like the idea of a content repository relying solely on one machine :)
Regards, Serge...
