JackRabbit persistence managers clarification

I'm trying to decide what type of persistence manager to use for my project. I read this wiki entry about persistenceManagers.

First of all, due to JCR-2802 (all non-bundle PM deprecated), there are only

BundleFsPersistenceManager
BundleDbPersistenceManager
      Mysql,H2,PostgreSQL,Oracle,Derby,MSSQL - PersistenceManagers

and all those InMem, Object, Xml PersistenceManagers are deprecated. (MemoryFileSystem still OK while InMemPM is deprecated ?)

So that as I see this, BundleFsPersistenceManager uses LocalFileSystem to persist files (is there a wiki entry that explains the means of how content is stored into files? - like different types of node properties such as nt:file) on filesystem and BundleDbPersistenceManager uses DbFileSystem to store the exact same files into DBMS ? Otherwise lucene indexing and full text searching wouldn't be possible right ?

So that the reasons are clustering and distributed nature of sy开发者_StackOverflow社区stems and atomicity...otherwise the database implementation would be redundant right ? Like this people have more choices.

MemoryFileSystem still OK while InMemPM is deprecated ?

Yes... It's a bit sad the the in-memory persistence manager is deprecated, because it allows to run fast unit tests. However, you could also use a database persistence manager together with an in-memory database (such as an H2 database).

is there a wiki entry that explains the means of how content is stored into files?

No, because this is an implementation detail and subject to change, you shouldn't ever need to parse or write such files yourself, and use Jackrabbit instead.

like different types of node properties such as nt:file

File content is stored in the DataStore. Node and property data and links to the data store is the persistence manager.

Otherwise lucene indexing and full text searching wouldn't be possible right ?

Lucene indexing is independent on the persistence manager or the data format the persistence manager uses. The Lucene indexing internally doesn't access the persistence manager data directly.

otherwise the database implementation would be redundant right ?

It's just that some people prefer storing all data in a database (for example because they already have a database and know very well how to operate / backup / maintain it). The majority seems to be OK to store the data in the file system directly, however there is no built-in transactional file based persistence manager in Jackrabbit. For this, you would need to use a Jackrabbit extension such as the (commercial) CRX from Adobe (disclaimer: I work for Adobe).