Two things.

1) I'd like email to participate in transactions. So I would like to access the database with hibernate within a transaction, then do say an SMTP RCPT TO: verifying that sending email will work. Then when I do the final commit I would like to commit the DB transaction as well as send the email. Is there a nice way to integrate this, maybe have an email object that participates somehow in the hibernate transaction?

2) I'd like to start a transaction in a filter before my struts servlet object is called then end the transaction possibly in a filter when the servlet object finishes the request. That way I can call associated objects ie usersHibernateDTO.getUsers() etc in my servlet and have have it work with an active session/transaction. So the DAO would return an object, the servlet could get associations.

But, would this transaction per request method be too much overhead? 99% of servlet requests usually hit the DB so I imagine this wouldn't be a problem. Would it be a bad thing if you created a number of transactions then didn't necessarily use them?

Thanks.

Hello fgkalways

> I'd like email to participate in transactions

Servers that participate in XA transactions need to provide explicit support for doing so. Most database servers (JDBC) and message queuing systems (JMS) do so. These are termed 'resource managers' in transaction parlance. Many other useful services don't have this capability. The two most commonly cited such are the filesystem and email (SMTP). There are two approaches you can take to address this problem:

1) Write a resource manager implementation to wrap the mail server, leading the transaction manager to believe it is a transactional resource. You still won't have full 2PC, but it's better than nothing. As there is no way to recall a mail message once it has been sent (i.e. no rollback), you will also need to implement the 'last resource' gambit. This is an advanced approach suitable only for those with substantial transaction system experience. If you don't understand the idea don't try it unassisted.

2) Use exception handling in your business logic. It's less elegant but also much more straightforward:

beginHibernateTransaction();
try {
doHibernateStuff();
sendEmail();
commitHibernateTransaction();
} catch(EmailFailedException) {
rollbackHibernateTransaction();
}

As for transaction overhead, a good transaction manager will use lazy initialization. This means very little overhead, especially as such a small proportion of transactions are null ops.

Hope this helps

Jonathan
http://www.arjuna.com