session, Transaction and worker threads

[teknokrat]

We are currently using Spring + webwork + Hibernate with the OpenSessionInViewFilter. Everything works great when confined to a single request. However, we now have to implement some long running processes that will be submitted by users of our app.

We were going to have spring wire up our services with daos, which would then be used by worker threads that the services started. However, we have no idea what this does to the opening/closing od sessions or the transaction demarcation.

Currently our transaction are demarcated declaratively around a single request. Our worker threads will need to make commits to the database several times over thie lifetime. What is the proper way of doing this?

Should we provide our service with a transaction manager? Which one? Should the threads open/close sessions themselves? Does each thread need its own unique dao, session, transaction???

thanks

[Colin Sampaleanu]

Transactions and any Hibernate Sesions associated with them are all thread-bound. If you need to spawn off work to another thread, then bascially you need to make those threads execute in a separate transaction, with related separate Session instances.

Note also that Hibernate Sessions are not thread safe, so Spring aside, it's not like you can just have a number of threads all working with the same session, unless you carefully synchronize them.

[teknokrat]

So what is the best practice for having spring manage these worker threads? The dao ( extended from HibernateDaoSupport) is threadsafe, but I assume that when it comes time for a database transaction it opens another session because it cannot find one in its threadlocal. However I don't understand how to tell the dao to close this session when the thread ends, and how to control transaction commits/rollbacks in the worker thread.

thank you

[gmatthews]

Based on the information you've given so far, I'd be looking at whether MDBs were the way to go.

There might be several things you haven't posted that rule this out (including that you may not be using an appserver?) but, the MDB option means you:

- don't have to code the worker threads,
- don't have to worry about the server getting clobbered by bursts of requests (throttled MDBs),
- don't have to worry about re-delivery of failed requests,
- can return from the user-request straight away while the MDB is still processing on a new thread. (fire and forget JMS messages)

Why do you have to commit several times?

[teknokrat]

No, I am not using an app server. Its a small project and doesn't require one. The use case I have is that once a job is submitted ( via the web ) a thread needs to go and spider a set of sites. After each site is spidered, the results need to be commited for that site, then onto the next sites.

Its seems to me that we should proxy the saveWebSiteDetails() method and have a spring bean factory instantiate our worker threads. However, we are new to spring and are unsure what the best practices are.

If you have a web app that needs to do asynchronous handling of certain requests ( say sending email or whatever ) and the results have to be committed to a database ( for auditing say ), how do you wire up your objects so that sessions/transactions work even though the http request has completed.