Terza puntata della serie sulle tecnologie di Jini: dopo avere parlato di lease e di eventi distribuiti, questo articolo completa la descrizione delle tecnologie su cui si fonda Jini parlando delle transazioni.

Introduzione

Data la natura dei servizi Jini, cioè il fatto che terze parti possono definirne sia la semantica sia l'implementazione, non è possibile definire a priori un'implementazione completa delle transazioni cui questi servizi devono partecipare.

Per questo Jini definisce un framework per facilitare lo sviluppo della semantica transazionale di un servizio e la gestione di transazioni scritte da terzi.

Le Jini Transaction Specification definiscono alcune interfacce e classi contenute nei package:

• net.jini.core.transaction
• net.jini.core.transaction.server

Inoltre queste specifiche stabiliscono alcune regole:

• le transazioni in Jini devono poter essere usate all'interno del protocollo two phase commit
• sono gestite col modello del lease
• se un lease scade prima che la transazione sia completata, questa si considera abortita

Sun fornisce l'implementazione di un transaction manager che espleta pienamente il protocollo two phase commit e può essere visto come servizio Jini o servizio RMI. L'unica limitazione menzionata dall'articolo è che non supporta le transazioni innestate.

Prima di passare alle transazioni in Jini, l'articolo propone un veloce ripasso di cosa siano le transazioni e di come funzioni il protocollo two phase commit.

Le transazioni ACID

Una transazione è un insieme di operazioni che devono o tutte andare a buon fine o tutte fallire.

Se una delle operazioni che compongono la transazione non può essere eseguita correttamente, nessuna operazione deve essere considerata valida e gli effetti di quelle eseguite prima di quella che fallisce devono essere annullati, lasciando invariato lo stato del sistema.

Inoltre, finché la transazione non ha completato l'esecuzione di tutte le operazioni che la compongono, nessuno degli effetti delle operazioni già eseguite deve essere visibile all'esterno della transazione stessa.

Affinché una transazione rispetti questa definizione deve possedere quattro proprietà, abbreviate nella sigla ACID:

1. Atomicità: tutte le operazioni che compongono una transazione sono eseguite con successo, oppure nessuna deve essere eseguita. 2. Consistenza: l'insieme delle operazioni eseguite deve lasciare lo stato del sistema in una situazione consistente. 3. Isolamento: l'effetto delle operazioni che compongono una transazione non deve essere visibile a oggetti esterni fino al completamento. 4. Persistenza, Durability: gli effetti della transazione devono essere durevoli e rimanere anche dopo il termine della transazione, quindi devono essere memorizzati su un supporto sicuro.

Il rispetto di queste norme comporta spesso problemi noti, primo fra tutti quello dell'acquisizione esclusiva delle risorse, locking, necessario per garantire atomicità e isolamento. Una soluzione efficiente al locking comporta spesso il nascere del problema del deadlock, cioè la situazione in cui due processi chiedono entrambi di riservare una risorsa già acquisita dall'altro, rimanendo bloccati in un abbraccio mortale.

Il protocollo two phase commit

Per transazione distribuita si intende una transazione in cui siano coinvolti più processi, partecipanti, che possono essere ospitati anche su host differenti.

L'articolo porta come esempio l'immissione di un ordine in un sistema amministrativo, evento che potrebbe da una parte scatenare la fatturazione dell'ordine e dall'altra avvisare il magazzino di approntare la spedizione.

È in questi scenari che il protocollo two phase commit diventa centrale: serve a coordinare più partecipanti in modo che il commit o l'aborto dell'operazione avvengano in modo coerente per tutti.

Conclusioni

L'articolo mostra che Jini, pur non imponendo una semantica transazionale unica per ogni servizio possibile, fornisce una struttura sufficientemente rigorosa per inserire le transazioni nel mondo distribuito.

L'incontro tra lease, proprietà ACID e two phase commit chiarisce bene il disegno di fondo: rendere praticabile la cooperazione affidabile tra servizi eterogenei in un ambiente dove partecipanti e semantiche possono cambiare.