Hi,

I've a question regarding session closing. I need to perform a batch transaction several times (read data froma flat file and update the database).

Here's the code that updates the database.

public void update(IMessage accountMessage, String action)
throws HibernateException {
Session session = null;
Transaction tx = null;
try {
session = HibernateSession.currentSession();
tx = session.beginTransaction();
ProcessHandler acctUserLoaderLog = new
AcctUserLoaderLogHandler();
acctUserLoaderLog.load(accountMessage, action);

} catch (Exception e) {
logger.error("Error happened")
} finally
{
try {
if (tx != null)
tx.commit();
tx = null;
if (session != null){
session.close();
}
}


I call update method for every record I read from the file.
Should I call close session for every record. or call just once. Becuase as it is, it throws an exception 'Session already closed'

Thu Aug 25 11:31:52:186 CDT 2005 MM:ERROR net.sf.hibernate.HibernateException: Session is closed
net.sf.hibernate.impl.SessionImpl.connection(SessionImpl.java:3292)
net.sf.hibernate.impl.BatcherImpl.prepareQueryStatement(BatcherImpl.java:65)
net.sf.hibernate.loader.Loader.prepareQueryStatement(Loader.java:779)
net.sf.hibernate.loader.Loader.doQuery(Loader.java:265)
net.sf.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:133)
net.sf.hibernate.loader.Loader.doList(Loader.java:1033)
net.sf.hibernate.loader.Loader.list(Loader.java:1024)
net.sf.hibernate.hql.QueryTranslator.list(QueryTranslator.java:854)
net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1544)


Thanks for your time
Ram
Need help with Hibernate? Read this first:
http://www.hibernate.org/ForumMailingli ... AskForHelp

Hibernate version:

Mapping documents:

Code between sessionFactory.openSession() and session.close():

Full stack trace of any exception that occurs:

Name and version of the database you are using:

The generated SQL (show_sql=true):

Debug level Hibernate log excerpt:

open session, begin transaction, update-update-update, commit transaction, close session . do not close the session after each update.

Thanks Dennis.

Great. Now can you log back in, and click on the little "yes" link right next to "Did it solve the problem?"

Is this safe for like millions of records ?

open session, begin transaction, get-get-get, update, get-get-get, update, get-get-get, commit transaction, close session

I'm pretty sure I had to use evict and flush to make my job run sucessfully. The job scans a whole table looking for candidates to do work on, marks them and hands off the ID to another thread to perform business logic centered around it.

The pattern you suggest works well for the business logic operation centered around an object, but for jobs that do full table scans ?

Maybe I should write a WiKi entry on that type of application, or maybe I am just missing the point.

Table scans and row count are irrelevant. Evict, Flush? Not sure why an evict is necessary and each Transaction.commit is an implicit flush anyways.

You mention "another thread". If you are using the HibernateUtil strategy, you will need something more complex - as each thread potentially has it's own session.

Yes. It worked. But when I process million of transaction should I call session.clear() periodically like once every 1000 records or so.

Thanks for your time
Ram

I think I read that Hibernate keeps all the get's in its level 1 cache, so for a whole table scan memory just fills up with rows that are now dead. I suppose what I'm putting up is that there are cases where the pattern the topic creator is already using would be better than the one you are citing, and some cases where the one you are citing would be fine if you evaluate you need to call evict() is necessary.

But I accept completely the one you are citing is the general case for most "business operation" work.

I may do 250,000 get's between each modify and flush(), so I forcefully evict() the dead objects once I've finished processing that row.

The other thread works fine in the pattern you are describing, both threads have their own Session object to work from.

Ram/chicagorarn: If you are doing a beginTransaction() commit() there is no need to call Session.clear() once a while. My problem is where you call beginTransaction() and then go on to do a get() for every row of a huge table, one huge transaction. Really in my case the processing of each row is a transaction in itself, but that then de-generates the design pattern into the one you started with.

Sessions keep all persistent objects in memory to provide == identity. This even works across transaction boundaries. Thus it is necessary, to actually call clear() on the session or to evict the objects to free that memory. Merely flushing (which is done on every commit) is not sufficient.