I'm questioning my implementation of the lock in various scenarios and I'd like to have some suggestion by user more expert than me.
I'm using two support class, named HibernateUtil and StorageManager.

HibernateUtil
Simply returns a singleton instance of session factory; obviously, it creates the session factory on the first call.

StorageManager
Encloses the common operations between the various entities. On its creation, it gets the session factory from HibernateUtil and store it into a static variable.
This class implements the session-per-request pattern and for this reason for every kind of request it basically does this things in sequence:

1. open a new session (from the session factory previously stored)
2. begin a new transaction
3. execute the specific request (depends on the specific methods of StorageManager invoked
4. commit transaction
5. close session

Of course, comment on this style are really appreciated.

Then, there are basically 3 categories of operations that implements point 3

Insert, Update or Delete entity

Code:
   session.save(entity);
        // OR session.update(entity) OR session.delete(entity)
   session.buildLockRequest(LockOptions.UPGRADE).lock(entity);

Get entity

Code:
        T entity = (T) session.byId(type).with(LockOptions.READ).load(id);
        // There are other forms of get, but they are pretty similar

Get list

Code:
         List<T> l = session.createCriteria(type).list();
         // Same here, various but similar forms of get list

Again, don't know if it is the right way to implement the various actions.
Also, and I think this is the real problem, whenever an error occurred, it is impossible to access to the datastore in any way, even from command line, until I manually stop the application that caused the problem.
What do you think about it? How can I solve the problem?

Thanks in advance.