Oak in AEM

AEM 6.0 was the debut version for Oak.
I’ve highlighted some interesting points about the new backend:

Transactional model

On login, each session is under the impression of operating on its own copy of the repository. Modifications from other sessions do not affect the current session. With the relaxed first committer wins strategy a later, session will fail on save when it contains operations which are incompatible with the operations of an earlier session which saved successfully.

[Source]  

Do and Don’t

• Concurrent changes from other sessions are not visible to a session until it gets refreshed. A session can be refreshed either explicitly by calling the refresh() method or implicitly by direct-to-workspace methods or by the auto-refresh mode;
• One of the key patterns targeted by Oak is a web application that serves HTTP requests. The recommended way to handle such cases is to use a separate session for each HTTP request, and never to refresh that session;
• Oak is designed to be virtually lock free as long as sessions are not shared across threads. Don’t access the same session instance concurrently from multiple threads;
• Oak scales to large number of direct child nodes of a node as long as those are not orderable;
• Using nodes with large multi value property would not scale well.

[Source]  

Understanding merge conflicts

Debugging merge conflict errors is now possible by enabling DEBUG logs on org.apache.jackrabbit.oak.plugins.commit.MergingNodeStateDiff and org.apache.jackrabbit.oak.plugins.commit.ConflictValidator

[Source]  

Indexing

Oak does not index as much content by default as does Jackrabbit 2. You need to create custom indexes when necessary, much like in traditional RDBMSs. If there is no index for a specific query, then the repository will be traversed. That is, the query will still work but probably be very slow.

[Source]