Oak no AEM

AEM 6.0 foi a versão de estréia do Oak.
Destaquei alguns pontos interessantes sobre o novo backend:

Modelo transacional

A cada login, a sessão tem a impressão de estar trabalhando com a sua própria cópia do repositório. Alterações de outras sessões não se refletem na sessão atual. Com a estratégia de relaxed first committer wins, uma sessão posterior falhará durante o salvamento, se ela possuir operações que sejam incompatíveis com as operações de uma sessão anterior, já salva com sucesso.

[Fonte]  

Faça e Não Faça

• Alterações concorrentes realizadas em outras sessões não serão visíveis enquanto a sessão não for atualizada (refresh). A sessão pode ser atualizada explicitamente, pela invocação do método refresh(), ou, implicitamente, por métodos direct-to-workspace ou pelo modo de auto-refresh;
• Um dos alvos mais importantes do Oak são aplicações web que sirvam requisições HTTP. A forma recomendada de lidar com esses casos é usar sessões separadas para cada requisição HTTP e nunca atualizar tal sessão;
• Oak foi desenhado para estar, virtualmente, livre de locks enquanto as sessões não forem compartilhadas entre threads. Não acesse a mesma instância de sessão concorrentemente, a partir de múltiplas threads;
• Oak lida bem com nós com muitos filhos diretos contanto que eles não sejam ordenáveis (orderable);
• Usar nós com propriedades multi valoradas muito grandes não escala bem.

[Fonte]  

Entendendo conflitos de merge

Agora é possível depurar conflitos de merge habilitando logs de DEBUG em org.apache.jackrabbit.oak.plugins.commit.MergingNodeStateDiff e org.apache.jackrabbit.oak.plugins.commit.ConflictValidator

[Fonte]  

Indexação

Por padrão, o Oak não indexa tanto conteúdo quanto o Jackrabbit 2. Você precisará criar índices personalizados quando necessário, como em um RDMBSs tradicional. Se não houver índice para a consulta específica, o repositório será atravessado. Isso significa que a consulta continuará funcionando, mas, provavelmente, será bastante lenta.

[Fonte]