Yet when I begin a transaction, then retrieve it later and attempt to commit, I recieve the error that no transaction exists to commit. I assume the servlet is closing the transaction automatically when the http request finishes on each servlet call - what, then, is the purpose of being able to mantain this userTransaction across sessions?
Is there any way to achieve what I want (I'm using Java with WAS)? I need some way to be able to start a transaction on the servlet, and wait for more information from the client in order to do certain statements before finally committing.
I've never tried this, but it is risky. What happens if the user goes for coffee with a lock on your database? It's more traditional to keep track of the information yourself and do all the updates when the user is ready. Or have a "locked" column so you can make sure nobody edits. The advantage of a locked field is that you can roll it back after time has passed. And databases that do table level locking don't bring your app to a halt.
besides being risky, I don't think that storing Transactions in HttpSession will achieve what I think you would expect.. i.e, from your post I think that you would like to "suspend" your transaction. As from documentation (i've read the link you provided) transactions must be committed or rollback at the end of request method call. I think that saving user transactions in http session is something that IBM introduced to support balancing / failover on different JVMs, but to be honest, I don't know how this mechanism works. I've never tried it...
I'd suggest you to follow Jeanne's suggestion...
Get meta with me! What pursues us is our own obsessions! But not this tiny ad:
Devious Experiments for a Truly Passive Greenhouse!