Java EE: Persistenza e Transazioni

Java EE: Persistence Api, Transazioni ed EntityManager
G.Morreale

Introduzione:

L'obiettivo di questo articolo è spiegare come poter controllare le transazioni dell'Entity Manager confrontando una gestione JTA da una gestione Locale.

Ripasso sulle Transazioni

Un transazione è una sequenza di operazioni.

Esempio di transazione in mysql:

BEGIN;

UPDATE Tabella3 SET colonna3 = x;

SELECT colonna1 FROM Tabella;

UPDATE Tabella2 SET colonna2 = y;

COMMIT;

La transazione può terminare correttamente, in questo caso una particolare istruzione: COMMIT, indica al gestore delle transazioni o al DBMS di rendere persistenti tutte le operazioni che compongono la transazione.

Oppure la transazione può terminare NON correttamente (in anticipo), in questo caso si utilizza un istruzione di ROLLBACK con la quale l'effetto delle operazioni finora eseguite dalla transazione non viene reso persistente.

Rifacendoci all'esempio se la lettura di "colonna1" ha un valore tale da richiedere l'annullamento della prima UPDATE allora si richiede il ROLLBACK, utilizzando l'apposita istruzione.

La transazione per poter essere tale deve godere di un insieme di proprietà, particolarmente significative nei sistemi in cui possono essere lanciate diverse transazioni contemporaneamente.

L'insieme di proprietà che caratterizzano la transazione viene indicato con l'acronimo ACID

• Atomicità: La transazione è un elemento indivisibile. Non è ammessa un esecuzione parziale della transazione.

• Coerenza: Una transazione deve rispettare i vincoli di integrità

• Isolamento: Se più transazioni vengono eseguite contemporaneamente, l'effetto deve prescindere dalle altre transazioni.

Riguardo L'isolamento sono previsti quattro livelli di isolamento:

• Read Uncommitted: Una transazione può leggere i dati scritti dalle transazioni concorrenti. Ciò vuol dire che se una transazione fallisce le altre possono aver letto dei dati non validi.

• Read Committed: Gli aggiornamenti di una transazione T1 vengono resi visibili a una transazione T2 non appena T1 effettua il consolidamento(Transazione terminata a buon fine - COMMIT)

• Repeatable Read: Gli aggiornamenti di una transazione T1 vengono resi visibili al consolidamento, in più T2 se è partita prima del consolidamento continuerà a leggere gli stessi dati(quelli non aggiornati da T1) fino alla sua fine(intendo la fine di T2).

• Serializable: Ha gli stessi vincoli del caso precedente, in più la lettura di un dato da parte di T1 provoca il blocco degli aggiornamenti fino al termine della transazione.

• Durabilità: Gli effetti di una transazione terminata correttamente devono essere persistenti nel tempo.

La concorrenza della transazioni porta a diverse anomalie(per capire attraverso degli esempi clicca qui)

• Lost Update: perdita di aggiornamenti effettuati da una transazione
• Dirty Read:una transazione T1 legge uno stato non più effettivo a causa di un rollback da parte di T2
• Unrepeatable Read:T1 rilegge gli stessi dati e li trova cambiati
• Phantom Read:Per effetto di inserimenti di nuove tuple una transazione riesegue una query ottenendo risultati diversi.

Di seguito una tabella riepilogativa che mostra quali anomalie vengono risolte con i diversi tipi di isolamento:

	Dirty read	Non repeatable read	Phantom read	Lost updates
Read uncommitted	SI	SI	SI	SI
Read committed	NO	SI	SI	NO
Repeatable read	NO	NO	SI	NO
Serializable	NO	NO	NO	NO

Java EE e la persistenza

Dopo aver brevemente richiamato i concetti chiave relativi alle transazioni, cerchiamo di capire quali sono gli attori e gli elementi che entrano in gioco quando si parla di ejb e persistenza in ambito Java EE.

Mapping ORM

Gran parte dei progetti software richiedono l'esistenza di un dbms per la gestione dei dati.

I dbms nella maggior parte dei casi sono di tipo relazionale, quindi l'elemento chiave è la relazione(una relazione è una tabella.. ) a differenza della programmazione object oriented  dove l'elemento chiave è l'oggetto.

Per far convivere questi due modi di vedere delle componenti esistono dei framework che si occupano di creare una corrispondenza biunivoca tra una rappresentazione ad oggetti e una relazione(http://it.wikipedia.org/wiki/Object-relational_mapping).

Di seguito un elenco di alcuni di questi framework:

• Hibernate
• EclipseLink
• Open JPA
• Kodo

Grazie a questi framework è rendere portabile(o quasi!!) un componente software rispetto al dbms usato(E' possibile ad esempio passare da mysql ad oracle senza modificare il codice del progetto).

JSR 220 - Enterprise Java Bean

La specifica JSR-220 prevede la definizione delle specifiche riguardanti le varie tipologie di Java Bean.

Visto la tipologia di articolo mi soffermerò su accennare solo a parte di tale specifica, ovvero quella relativa alle Persistence API.

Si è parlato di mapping tra relazione ed oggetti.

Bene, gli oggetti sui quali si mappano le relazioni (Tabelle e righe) sono gli EntityBean.

Un EntityBean è una classe dotata di particolari annotation (Es. @Entity) (o in alternativa di opportuni descrittori xml) e altri vincoli.. in grado di rappresentare una relazione.

Chi si occupa di gestire gli EntityBean?

Gli EntityBean sono gestiti dall'EntityManager. 

L'EntityManager, è l'oggetto associato al persistence context.

Il persistence context è un insieme di istanze di entity identificate univocamente. All'interno del persistence context gli entity e il loro lifecycle sono managed(sotto il controllo del persistence context).

Persistence Unit:Indica quali classi sono gestite da un determinato EntityManager nonché a quale datasource fanno riferimento, è una sorta di "elemento di configurazione"

L'EntityManager, quindi, interagisce con un persistence context al fine di effettuare creazione, eliminazione, aggiornamento, ricerca e query sui vari entity del contesto, nonchè comunicare con il db al fine di permettere il mapping tra la rappresentazione ad oggetti e quella relazionale dei dati.

Transazioni, Scope etc.. Operare delle scelte

Le scelte da operare sono diverse:

Chi decide quando creare o eliminare un EntityManager? L'applicazione o il container?

Le opzioni sono due, o lo gestisce il container o lo gestisce l'applicazione generando e chiudendo con apposite istruzioni l'entityManager.

Se vogliamo che in automatico venga generato e distrutto un entityManager dal container l'unica possibilità è quella di optare per un EntityManager JTA

Container-Managed Persistence Context (JTA Entity Manager)

@Stateless

public class TestImpl implements TestLocal

{

//EntityManager ottenuto tramite dependency injection

@PersistenceContext EntityManager em;

    public Dato getDato(Long id)

    { 

        return em.find(Dato.class, id); //Uso l'entityManager senza occuparmi di crearlo, e distruggerlo

    }

}

Se invece decidiamo di controllare la vita dell'entityManager si può optare per un entityManager JTA oppure entityManager ResourceLocal.

Application-Managed Persistence Context (JTA Entity Manager)

@Stateless

public class TestImpl implements TestLocal

{

//EntityManager ottenuto tramite dependency injection

@PersistenceUnit EntityManagerFactory emf;

    public Dato getDato(Long id)

    { 

             EntityManager em = emf.createEntityManager();//Inizializzo l'entityManager

        Dato = (Dato)em.find(Dato.class, id); //Uso l'entityManager

             em.close();//Chiudo l'entityManager            

    }

}

Application-Managed Persistence Context (Resource Local Entity Manager)

@Stateless

public class TestImpl implements TestLocal

{

    public Dato getDato(Long id)

    { 

             EntityManagerFactory emf = Persistence.createEntityManagerFactory();

             EntityManager em = emf.createEntityManager();//Inizializzo l'entityManager

             em.getTransaction().begin();

        Dato = (Dato)em.find(Dato.class, id); //Uso l'entityManager

             em.getTransaction().commit();

             em.close();//Chiudo l'entityManager            

    }

}

In entrambi i casi viene creato(createEntityManager()) e distrutto(close()) dall'applicazione.

Però con la gestione JTA la transazione inizia e termina con l'inizio e la fine del metodo nel secondo caso invece l'inizio e la fine della transazione sono decisi dallo sviluppatore (quindi dall'applicazione)

Inoltre nel caso di transazioni JTA controlled, il rollback viene richiamato nel caso in cui si verifica un eccezione all'interno del metodo. Altra possibilità di Rollback è l'invocazione del metodo setRollbackOnly (appartenente all'interfaccia EJBContext).

Un'altra scelta da effettuare, in qualsiasi dei casi visti precedentemente, è quella relativa allo scope del persistence context.

Le opzioni sono due:

• Transaction Scoped Persistence Context
• Extended Scoped Persistence Context

Questa scelta influisce sulla vita di un persistence context.

Nel primo caso esso viene generato e distrutto insieme all'inizio e alla fine di una transazione sia essa gestita da un JTA EntityManager che da un ResourceLocal EntityManager.

Nel secondo caso invece, la vita del persistence context non è legata all'inizio e alla fine di una transazione, ma è legata alla vita dell'EntityManager.

Nel caso in cui l'EntityManager è gestito dal container il persistence context viene creato non appena esso è ottenuto attraverso operazione di lookup o dependency injection, nel caso di EntityManager gestito dall'applicazione esso viene creato e distrutto rispettivamente sulle istruzioni EntityManagerFactory.createEntityManager(), EntityManager.close().

Conclusione

Questo è un articolo in un certo senso "difficile" in quanto entrano in gioco diversi e diversi concetti.

Più che altro è un quadro d'insieme per chi già conosce questi concetti, spero però che sia anche uno punto di partenza per chi non li conosce ancora.

Riferimento: JSR 220 Documentation.