Arquitetura interna - Storage plugável e eventos

Um sistema distribuído pode precisar manipular um grande volume de dados, mas poucos dados de cada vez. Além disso, ele deve ser tolerante a falhas na comunicação, bem como nas máquinas que utiliza.

Ao utilizar SharedObjects para desenvolver um sistema distribuído, a comunicação torna-se totalmente transparente, mas não há, no momento, um suporte robusto a falhas nas máquinas. Por exemplo, cada SharedSpace é identificada por um url que inclui a porta em que ela escuta. Se a máquina onde ela roda perde a conexão ou é desligada, esta SharedSpace, bem como os dados que ela guarda, são perdidos.

O suporte à reconexão está previsto desde a concepção, e na versão 0.5 direcionamos o pacote no sentido de permitir, futuramente, a existência de objetos persistentes que possam ser recuperados após uma reinicialização. Esse suporte é chamado de Armazenamento Plugável (Pluggable Storage). A idéia é de que o mapa de objetos de um SharedSpace possa ser implementado de diferentes formas e múltiplos mecanismos de armazenamento podem coexistir.

Nessa visão, o armazenamento de objetos deixa de ser limitado a um HashMap na memória. Atualmente, esta continua sendo a implementação default e a única presente, mas o desenvolvedor poderia, com pouca reescrita, implementar seu próprio mecanismo. No futuro, isso será configurável durante a inicialização.

Além disso, foi adicionado ao mecanismo de armazenamento uma série de eventos (veja o pacote br.shob.event) disparados pelo Storage:

• Addition: quando um objeto é adicionado ao storage. No caso dos objetos compartilhados pela SharedSpace, isso acontece quando a aplicação compartilha um objeto. No caso do cache, quando a aplicação resquisita um objeto pela primeira vez.
• Change: quando um objeto é substituído no storage. Isso ocorre entre os objetos compartilhados quando uma transação termina com commit, e no cache, quando uma cópia é atualizada.
• Remove: quando um objeto é removido do storage. Atualmente, isso não acontece, mas podem existir futuramente Storages com capacidade limitada ou caches que coletam entradas sem uso por muito tempo.
• Lock e Unlock: estes eventos são internos e atrelar código a eles é perigoso: durante uma operação no storage, o mapa garante o acesso sincronizado à chave (no caso, o nome global). Assim, quando uma referência pede a validação de sua cópia, ou o início de uma transação, outras threads da mesma máquina aguardam que o processo termine antes de fazer suas verificações. Essas regiões críticas são bastante pequenas, porém atrelar eventos a Lock tende a diminuir a disponibilidade dos objetos. Atrelar métodos a Unlock não fornece garantias de que o objeto ainda estará livre quando o método for executado.

Além de uma séria revisão, esta parte da arquitetura sofrerá grande expansão nas próximas versões, inclusive com suporte a Storages externos fornecidos pelo desenvolvedor, na linha do que acontece com drivers JDBC.

• Anterior: Leases: percebendo mudanças