• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

transactions across jsp pages best practice

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am creating a web application using a mvc jsp/servlet architecture. I am having a problem deciding how to maintain transaction state across multiple pages. Eg I have say three jsp pages which will each save information to separate database tables which comprise a single transaction. The problem arises when the user decides to hit the back button and goes back to the first page, at this point in the transaction three records have already been posted to the database (not comitted as I have set autoCommit to false). Now if the user decides to make changes to the first page and hit the submit button I would essentially like to rollback all transactions to that first page and start over again.
if the user decides to hit the back button to the second page(coming from the third page) I would like to rollback to that point only.
I hope you see the general trend. Of course the rollback would only occur when the submit button is pressed on the page you backed up to.
I have seen solutions by setting tokens in the request and session objects, but this only allows you to perform the transaction only once.
Now I was thinking that when processing each page I could set a savepoint and manipulate the rollback scenarios as described above theoretically( haven't tried it as yet)
Questions
1)is this feasible?
2)I think savepoints are only available from jdk1.4 and up how would I implement under jdk1.3
3)What is the best practice to follow in such scenarios?
Any links, all advice would be highly appreciated.
Gary
 
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would be very careful about maintaining transactions across http requests in general. What happens if the user posts jsp1, then posts jsp2 and then goes for lunch?
You will be sitting there with a transaction open, which is presumably locking rows in the DB.
I think it would be better, if possible to save up the data in the session, and then at the end of the third page, start and finish the transaction in one request.
Savepoints might work, but only are of benefit if you are willing to commit a part of the transaction. I.e. you roll back to the previous save point and commit from there. Otherwise the above scenario will still apply.
Savepoints (I think) are available as of JDBC 3.0, but presumably you will need a JDBC 3 compliant driver to use them.
Jesse
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Basically this is the long transactions problem. If you REALLY and TRULY need to have an actual honest-to-god SQL transaction that spans three tables then you should NOT write to each table at the end of each page. Instead, cache the data somewhere like the HttpSession until the very last page and then write to all of the tables within a single transaction.
Long transactions are a nightmare. You've pointed out one problem but there are a million more. What if the user walks away for an hour between screens two and three? Do you want to leave locks on the tables during that time? What if they *never* finish the last page?
The best solution is to just NOT do things this way. Either implement compensation logic (e.g. make sure that you can undo your writes), or hold the transaction until the very end (preferred).
Kyle
 
gary stines
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I did think about saving this information in the session but I was also thinking that there may be problems storing all these objects in the session. This may lead to memory problems within the JVM particularly with a web application(large number of users).
In other other words wouldn't it be better for the database to handle this type of situation rather than leaving it to the servlet container.
Also regarding the question about the user leaving the machine in the middle of a transaction. I could have the session timeout say within 10 mins and handle rollback/cleanup within the HttpSessionBindingListener interface using the valueUnbound method.
 
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well- you really should measure what the impact is on the server by doing some load testing. You can speculate all day- but there's nothing like hitting the site using JMeter to blast the site and see how your container handles it-
If find that the session approach is too resource intesive, and you need to save to the database, I wouldn't leave the database connections open. I would represent each submit as an atomic transaction. So first page creates the row, second page updates(along with a status field), third page updates and concludes the transaction. You'd need to do a lookup in each resulting page for the shoppingcart id- and it would result in a ton of empty shopping carts in your db(You'd need write cleanup scripts/program to look for certain status in your database to delete the old, unused carts). If your users login- it would be easier to link the users profile to a current shopping cart id, which would allow you to get back that data for the end user.
[ November 13, 2002: Message edited by: Matthew Brown ]
reply
    Bookmark Topic Watch Topic
  • New Topic