• 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
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

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: 39435
768
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: 1166
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...
 
I'm THIS CLOSE to ruling the world! Right after reading this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!