Hibernate: Session and Transaction

[miguel lisboa]

this post continues this conversation.

here's what i got from Hibernate API:

A transaction is associated with a Session and is usually instantiated by a call to Session.beginTransaction(). A single session might span multiple transactions since the notion of a session (a conversation between the application and the datastore) is of coarser granularity than the notion of a transaction. However, it is intended that there be at most one uncommitted Transaction associated with a particular Session at any time.

 public class ConvencaoDao implements InterfaceDao {
InterfaceDao dao;
Session s = HibernateUtil.getSession();
Transaction t = null;
Convencao cv;
public void criaOuActualiza(Object o) throws 
HibernateException {
 
t = s.beginTransaction();
 
s.saveOrUpdate(o);
 
t.commit();
}
 
public Object obtemPorId(Long id) throws
HibernateException {
 
t = s.beginTransaction();
 
cv = (Convencao) s.load(Convencao.class, id);
 
t.commit();
 
return cv;
}
 
public void elimina(Long id) throws 
HibernateException {
 
t = s.beginTransaction();
 
cv = (Convencao) s.load(Convencao.class, id);
 
s.delete(cv);
 
t.commit();
}
 
public List todos() throws  HibernateException {
 
List lista;
 
lista = s.find("from Convencao");
 
return lista;
}
 
public void setDao(InterfaceDao dao) {
this.dao = dao;
}
} 

so now i dont need to declare throws InfrastructureException and/or HibernatException

Notice i never use:

 HibernateUtil.closeSession(); 

and also use a overall Session, created at top of class: am i playing with fire? (my app is a standalone desktop for crud use - only one single user ever)

One pratcal advantage i get from this aproach is that i dont need anymore to worry about re-opening a session everytime i use one.

this other aproach (the correct one?):

 public void criaOuActualiza(Object o) throws HibernateException {
Session s = HibernateUtil.getSession();
t = s.beginTransaction();
s.saveOrUpdate(o);
t.commit();
HibernateUtil.closeSession();
} 

forces me to pay very carefull atention to the existence of sessions in my code - see this example:

 public void testElimina() throws HibernateException {
Convencao y = new Convencao();
dao.criaOuActualiza(y);
                s = HibernateUtil.getSession();//here, else ... error
dao.elimina(y.getId());
        s = HibernateUtil.getSession();//here again
                int nInicial = ((Integer)s.iterate(hql).next()).intValue();
assertEquals(2, nInicial);
} 

[ March 26, 2005: Message edited by: miguel lisboa ]

[miguel lisboa]

i just read this in hibernate API:

  Session sess = factory.openSession();
 Transaction tx;
 try {
     tx = sess.beginTransaction();
     //do some work
     ...
     tx.commit();
 }
 catch (Exception e) {
     if (tx!=null) tx.rollback();
     throw e;
 }
 finally {
     sess.close();
 } 

If the Session throws an exception, the transaction must be rolled back and the session discarded. The internal state of the Session might not be consistent with the database after the exception occurs. <hr></blockquote>
do i get back to (moderate) try catch?
my answer is yes, in view of the need of the roll back.

do you agree?
[ March 26, 2005: Message edited by: miguel lisboa ]

[David Harkness]

Originally posted by miguel lisboa:
do i get back to (moderate) try catch?
my answer is yes, in view of the need of the roll back.

do you agree?

Yes, to be make your application robust in the face of failures, you should be doing this. Ninety-nine times out of a hundred, it won't matter. But problems do occur, even in a single-user desktop application.

Sessions are designed to be lightweight and quick to create, thus the use of the SessionFactory which maintains the configuration. You will be fine creating one for each transaction with your application.

However, you don't normally want your DAO managing the transactions or session. This should be left to the business logic. If you are going to change a user's email address, for example. You want to

begin a transaction

find and load the user

set the new email address

save the user

flush the session

commit the transaction

This is another place Spring helps out. It provides classes to maintain thread-bound sessions and transactions. When a session is needed, if the thread doesn't have one already, a new one is opened and bound to the thread.

This is important because the session maintains the unit of work to flush to the database. If you load it in one session and then save it in a different session, you'll have to use saveOrUpdateCopy() so it can reload the user to tell which objects and values have changed.

For managing the transactions, Spring provides EJB-like method-level transaction demarcation. Spring will begin and commit/rollback transactions based on each method's transaction property.

[David Harkness]

Also, I had a recommendation for your DAO class. First, what does the "dao" instance variable do? I don't see it being used -- though there is a setter.

Anyway, since all the methods are typed against Object instead of the domain object's interface, Convencao, you could create a base class that would supply 90% of the methods for all of your DAOs.

Pull the different pieces out of each DAO and make them constructor arguments: domain class and domain class's name. Then all the other methods you have can move to the base class.

public class BaseDao implements InterfaceDao
{
    Session s = HibernateUtil.getSession();
    
    Class domainClass;
    String domainClassName;  // no package, just the class's name
    
    public BaseDao(Class domainClass, String domainClassName) {
        this.domainClass = domainClass;
        this.domainClassName = domainClassName;
    }
    
    public void criaOuActualiza(Object o) throws HibernateException {
        // no change
    }
    
    public Object obtemPorId(Long id) throws HibernateException {
        Transaction t = s.beginTransaction();
        Object o = s.load(domainClass, id);
        t.commit();
        return o;
    }
    
    ...
}

If you go with the method suggested in the Hibernate documentation, using a common base class will save you tons of cut-n-paste code. As well, if you need to change it in the future, it's all in one place.

[miguel lisboa]

First, what does the "dao" instance variable do? I don't see it being used -- though there is a setter.

that setter exists because of some mocks i was working on

BaseDao looks really great!

I made a quick search in hibenate docs but wanst unable to find the BaseDao reference you mentioned; can you pls tell me where i can find
it?

[David Harkness]

Originally posted by miguel lisboa:
BaseDao looks really great!

I made a quick search in hibenate docs but wanst unable to find the BaseDao reference you mentioned; can you pls tell me where i can find
it?

Thanks! I wrote it using your ConvencaoDao as a starter for you. The BaseDao I wrote for my work is based off the same idea, but it uses Spring's HibernateTemplate and wouldn't be very helpful. The main concept, though, is very applicable: create a base class that will handle 90% of the work.

The only things each domain class DAO I have to write has are the constructor call to pass in the class and its name and any search methods specific to that object.