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.
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]
Seja o Primeiro a Comentar