Is it posible to use MongoDb as persistence storage?

[eugeney]

MongoDB can be configured for use for BinaryStorage. Is it possible to use MongoDB as persistence storage for storing repository information?

[rhauch]

No, it is not possible to use MongoDB for node storage. ModeShape requires the node storage to be transactional, and MongoDB does not satisfy those requirements.

[rhauch]

BTW, the reason ModeShape can use MongoDB and other non-transactional systems for binary storage is because each binary is treated as an immutable and idempotent piece of data, so the binary will be stored correctly even when multiple threads/sessions attempt to store the same binary value.

[eugeney]

Thanks for your answers.

I look at code, I'm not sure that transaction is need.

If I understand correct DocumentStore works in next step

- start transaction

- lock document by ids

- update documents in batch in RelationalDb.persistContent method

- commit transaction

MongoDB allows update many documents in isolated mode. So ModeShape can push all document in one request with '$isolated' operator. As result, update documents in DB will be consistent.

What you thinks?

[rhauch]

The DocumentStore operations are performed per thread/session, but multiple threads/sessions can certainly be active simultaneously. It might be possible to constrain a client to ensure that operations are performed in an isolated way, but that would certainly not scale nor perform well. Bottom line is that the ModeShape architecture requires that a DocumentStore implementation support concurrent transactions that are atomic, consistent, isolated, and durable (ACID), and that the persistent storage used be strong consistent. MongoDB simply does not satisfy these requirements, and ModeShape could not guarantee its behavior with a MongoDB backend for node storage.

[hchiorean]

MongoDB only provides ACID-like constraints at a document-level. It doesn't offer these guarantees for collections of documents (i.e. multiple documents) which ModeShape would require.

Mongo's two-phase commit mechanism only offers "transaction-like" semantics which is not good enough for ModeShape, especially because this means "dirty reads" are possible (see https://docs.mongodb.com/v3.2/tutorial/perform-two-phase-commits/#background). With dirty reads, even though ModeShape excludes multiple overlapping writers using exclusive locking, concurrent JCR sessions might see not yet committed data which in turn could cause JCR constraint failures (i.e. operations which should fail, succeed, or the other way around)