I am new to hibernate , could someone please let me know if there is any problem with doing the following to lazy intialize a collection in a web app .

I hava a DAO
In the app I get the user
UserDAO.getUser(pk);

Later in the app I load the roles only when I need them
UserDAO.loadRoles(user);


The load roles looks like this


public void loadRoles(User user) {

Session session = null;
Transaction tx = null;

try {

session = HibernateUtil.currentSession();
tx = session.beginTransaction();
session.lock(user, LockMode.NONE);
Hibernate.initialize(user.getRoles());
tx.commit();

} catch (HibernateException e) {
e.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
} finally{
try {
HibernateUtil.closeSession();
} catch (HibernateException e) {
e.printStackTrace(); }
}

}



Seems to work fine , my question is is this bad practice ? I have already looked into the docs for long running transactions and keeping the hibernate session in http session and would rather pursue a option where I don't have to persist the hibernate session . Also , when I take out the session.lock .. it does not work .

tx = session.beginTransaction();
tx.commit();
you don't need it since you're not updating any objects

session.lock(user, LockMode.NONE);
Hibernate.initialize(user.getRoles());
can be replaced by
session.refresh(user); (if someone has updated the object, you'll see the changes)
user.getRoles();

Why on earth reading does not need transaction ?
Please refer to the famous Gavins Grrrrmmrg posts on that subject.

This is for sure something to add into the book.

cannot find the grrrr post,
what does tx.commit() do if the only things you do is reading objects?

i must lack knowledge about this, excuse me

To keep read consistency, you must be in Tx.
If you don't your driver et db will be in autocommit=true (not sure of me) and provoque overload due to tx creation.
Anybody better than me correct it if I'm wrong.

when you use the session, it's based on a jdbc connection, so automatically a transaction is started ...
Now if you write tx.commit() or let auto-commit do his work, is it different?

Yes because auto commit will be done each time a statement is flushed into the DB, if you explicitly do a commit() then you can avoid extra commit per flush.
And my first remark stray true.

ok fine, i understand,

merci Emmanuel

"tx.commit()" ends transaction and releases read locks.

i think it could be usefull to explain that in the doc