• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Knute Snortum
  • Bear Bibeault
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Tim Holloway

Mantaining open transactions across servlet calls

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Working in a servlet, Websphere Application Server allows you to store UserTransaction objects in the HttpSession and retrieve it later, previously with a wrapper class, but now automatically:

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere.javadoc.doc%2Fpublic_html%2Fapi%2Fcom%2Fibm%2Fwebsphere%2Fservlet%2Fsession%2FUserTransactionWrapper.html

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.
 
author & internet detective
Posts: 39343
755
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 1151
38
IBM DB2 Netbeans IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Thowne,

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...
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!