Una transazione è un’indivisibile unità di lavoro che deve completare con il successo di ogni singola operazione, se questo non avviene essa deve essere abbandonata e tutti gli elementi coinvolti devono tornare allo stato iniziale.
Normalmente, si parla di transazione nel contesto dei dbms dove essa consiste in un insieme di istruzioni di update al database che vengono effettivamente eseguite tutte insieme (commit) se nessuna di esse è fallita, in caso contrario il database viene riportato allo stato iniziale (rollback).
Nel contesto JEE, invece, le transazioni possono includere altre risorse dati, come una variabile di stato di uno stateful session EJB, di un JMS messages e naturalmente di un’entity EJB.
La propagazione delle transazioni attraverso gli EJB è silente e automatica. Ogni transazione avrà un identificatore oltre ad altre informazioni allegate.
Un metodo chiamato su un EJB trasferirà automaticamente le informazioni di transazione da un EJB all’altro, ache se esso risiede in un altro container o addirittura su un altro server con supporto JEE.
Il tutto è possibile grazie al protocollo IIOP (Internet Inter-ORB Protocol), ovvero un EJB richiede un ogetto specificando un nome univoco a un altro server attraverso il protocollo CORBA, come di solito fa un client stand alone per richiamare un modulo EJB su un server.
L’application server ha un gestore delle transazioni (a volte chiamato monitor) che memorizza i dati di ogni oggetto coinvolto in una transazione in modo da essere in grado di riportare tutto allo stato iniziale in caso di fallimento.
Attraverso l’application server è possibile regolare vari livelli di isolamento delle transazioni a seconda del contesto in cui ci si trova, potrebbe infatti capitare di avere situazioni in cui più transazioni devono accedere agli stessi oggetti e in alcuni casi, se si è sicuri che questo non provochi inconsistenza, si può permettere l’accesso nonostante un’altra transazione in corso.
Naturalmente le transazioni devono sempre rispettare le classiche e famose proprietà ACID (Atomic,Consistent,Isolated,Durable) .
Come la persistenza anche le transazioni, in JEE, possono essere gestite o dal container o dal BEAN.
Nel primo caso il programmatore non deve implementare manualmente il codice necessario alla gestione della transazione ma essa viene definita dal descriptor xml e gestita dal server, nella maggior parte delle circostanze è utilizzabile questo tipo di transazione.
In conclusione con la tecnologia Enterprise è possibile, grazie al completo controllo dell’Application Server, strutturare transazioni complesse e distribuite su tipi di dati diversi con un notevole risparmio in termini di complessità e tempo, sopratutto grazie all’utilizzo di IDE che automatizzano il building dei descrittori XML esonerando il programmatore da questa incombenza.
Post correlati
Tag: ACID, application server, bean, commit, CORBA, ejb, IIOP, java, Java Enterprise, jee, jee transaction, rollback, transazione
