Hibernate Part 1

by on Mar.21, 2012, under Uncategorized

Hibernate è un framework che offre supporto alla persistenza.
Essendo nato prima di JPA, non sfrutta il meccanismo di dependency injection sul gestore della persistenza (equivalente all’Entity Manager),  che prende il nome Session.

La Session Factory genera una Session, che gestisce il ciclo di vita degli oggetti persistenti.
La Session deve essere usata come Factory delle transazioni perchè ai tempi di Hibernate non c’erano le transazioni container-managed, quindi devono essere definite (commit e rollback) nel codice dl metodo che gestisce gli oggetti persistenti.

Gli stati di un oggetto persistente e le sue transizioni di stato , sono equivalenti a quelle di JPA.

Vediamo come deve essere una classe concreta per generare le classi DAO relative ai bean per un’applicazione che implementa una libreria.


public class TxHibernateDAOFactory extends DAOFactory {

	private static final SessionFactory sFactory;
	static {
        try {
            /*
             * Build a SessionFactory object from session-factory configuration
             * defined in the hibernate.cfg.xml file. In this file we register
             * the JDBC connection information, connection pool, the hibernate
             * dialect that we used and the mapping to our hbm.xml file for each
             * POJO (Plain Old Java Object).
             *
             */
            sFactory = new Configuration().configure().buildSessionFactory();
        } catch (Throwable e) {
            System.err.println(“Error in creating SessionFactory object.”
                + e.getMessage());
            throw new ExceptionInInitializerError(e);
        }
	}

	private  void terminate() {
	sFactory.close();
	}

	public static TxHibernateDAOFactory get(String whichFactory) {
		try {
			return (TxHibernateDAOFactory) TxHibernateDAOFactory.getDAOFactory(whichFactory);
		}
		catch (Throwable t) {
			return null;
		}
	}

public static Session getSession()
{
	return sFactory.openSession();
}

	public static void release(TxHibernateDAOFactory factory) {
		try {
			factory.terminate();
		}
		catch (Throwable t) { }
	}

	@Override
	public AuthorDAO getAuthorDAO() {
		// TODO Auto-generated method stub
		return new TxAuthorDAO();
	}
	@Override
	public BookDAO getBookDAO() {
		// TODO Auto-generated method stub
		return new TxBookDAO();
	}
	@Override
	public PublisherDAO getPublisherDAO() {
		// TODO Auto-generated method stub
		return new TxPublisherDAO();
	}
}

Notiamo subito che oltre a (continue reading…)

Leave a Comment :, , , , , , , , , , more...

Java Persistence Architecture part 4

by on Feb.06, 2012, under Uncategorized

Differenza tra container pesante e container leggero

Modello a “Container Pesante”

EJB usa un modello a “container pesante”: il client riceve uno stub per il componente SB1, tramite lo stub invoca il metodo che viene sempre e comunque intercettato dal container, in questo modo il container nasconde le modalità di invocazione e la gestione del pool di istanze, il cliente crede di effettuare una chiamata diretta al SB invece non lo è.

Modello a container leggero (JPA senza dependency injection)

JPA invece di per se offre un modello a container LEGGERO, i componenti entity sono accessibili direttamente al client, tanto che possono essere istanziati come POJO all’interno dello stesso codice cliente.
Lo svantaggio è la mancanza di trasparenza: ad esempio devo necessariamente invocare un Entity Manager passando remotamente l’istanza di un oggetto entity se voglio rendere quell’entity persistente.

 

Leave a Comment :, , , , , , , , , , , more...

Java Persistence Architecture part 3

by on Feb.05, 2012, under Uncategorized

                       Ciclo di vita delle Entità

Un’ Entity viene considerata managed quando la passo a entityManager.persist(entity), l’entityManager provvede da quel momento ad assegnare un id unico all’entity e ad agganciarla al DB, cioè tutte le operazioni fatte sulla entity vanno riportate al DB.

A volte può essere necessario dover temporaneamente fare il detach (staccare) della entity dal DB, ad esempio per voler serializzarla su un disco fisso o trasferirla ad una destinazione remota, a quel punto la entity passa allo stato di detached.

  • Problema1
    Se diverse copie della entity detachata vengono diffuse e modificate, come fa l’entityManager a gestire una loro riattivazione allo stato Managed?
  • Soluzione1
    L’entityManager si accorge di avere a gestire copie diverse della stessa entity grazie all’id univoco. A questo punto può limitarsi ad aggiornare il DB ad ogni transazione ricevuta oppure adottare un meccanismo di gestione dei conflitti.

Lo stato removed consiste nel rimuovere dal DB tutte le informazioni relative ad un’entity, tale entity che transita in questo stato non avrà più il suo ID univoco.
Generalmente si tende a effettuare le operazioni di modifica sul DB all’interno di una transazione: l’allineamento col DB viene fisicamente effettuato quando la transazione raggiunge il commit.

  • Problema2
    Posso avere un problema di transazioni concorrenti:
    es.A.x=15

    La Transazione2 effettua una modifica su una riga condivisa del DB quando la Transazione1 ci sta ancora lavorando. Tale scenario è possibile quando T1 e T2 sono lanciate ad esempio da 2 istanze dello stesso componente EJB, ed agiscono su copie diverse dello stesso Entity. (continue reading…)
Leave a Comment :, , , , , , , , , , , , , , , , , , , , , , , , , more...

Java Persistence Architecture part 2

by on Gen.26, 2012, under Uncategorized

A volte può essere utile specificare tramite delle annotazioni la cardinalità delle relazioni fra entità  ( intese come singole righe di DB).

In questo caso so che c’è una relazione many-to-many tra le due entità, se rimuovo un libro non è detto che io possa rimuovere il relativo autore o viceversa.

Invece:

in questo caso abbiamo una relazione one-to-one: se l’entity manager è conscio di ciò attraverso apposite annotazioni, può rimuovere una fattura se il relativo ordine è stato cancellato, e viceversa.

Una sostanziale differenza tra i mondo ad oggeti e il mondo RM è che tra relazioni basta una chiave esterna per poter mettere in relazione due tabelle: una delle due tabelle possiede come riferimento la chiave dell’altra.
Nel mondo ad oggetti invece se un’istanza e1 della classe A possiede un riferimento ad e22 della classe B, ciò non è sufficiente a determinare partendo da e2 l’istanza e1 che lo referenzia, quindi serve anche un riferimento che va da e2 ad e1 per avere una relazione bidirezionale.
Attraverso le annotations posso decidere se una relazione deve essere monodirezionale o bidirezionale.

Leave a Comment :, , , , , , , , , , , , , more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!