Session closed on item writer commit

[eloyot]

Hi Folks,

I'm trying to create a Hibernate aware item reader that uses a dao to create the Hibernate cursor used to read items.

The dao uses SessionFactory.getCurrentSession() to get the session.

This works fine until the first time the writer hits it's commit interval. The commit appears to close the session used by the cursor.

The source code for the HibernateCursorItemReader appears to create a local session for this purpose but that won't work for my dao.

Can someone explain this behavior and provide some thoughts on a work around or is this the wrong approach.

Thanks,

Ed

[Dave Syer]

Can someone explain this behavior and provide some thoughts on a work around or is this the wrong approach.

Difficult without some more information. What do you mean "that won't work for my dao"?

[eloyot]

I'd prefer to keep my dao consistent with my other daos and use sessionFactory.getCurrentSession() rather than creating an external session and passing it around. This would keep session management isolated to my dao layer, leaving only the cursor (which looks pretty much like any other iterator) outside the dao layer.

Can you tell me why the session is closed instead of just a commit on the transaction?

Thanks,

Ed

[Dave Syer]

I don't think Spring Batch would close the current session, but the transaction manager probably does when it commits. That should be fine unless a) your reader is caching ahead of the next call to read(), or b) there is a retry. Are you experiencing other problems? In either of those cases your items will be encountered in processor and writer *after* the session is closed. A workaround would be to re-attach them to the current session in an item processor (session.lock(item)). You can also mark the step as having a "transactional reader" (the flag name changed in 2.1 slightly; in 2.0 it's a namespace attribute reader-transactional-queue). The effect of that is to re-execute the reader and not cache the items between chunks on a retry. Let me know if that works because the flag was designed for use with JMS item readers, so if it helps for custom Hibernate implementations that would be interesting (and we could change the name).