Help With Transactions, iBATIS, and Session Views.

[saden1]

Problem:
I'm working on code that does groups and user management. The objective is to add and remove user from a group. When the administrator of the group is done they have the ability to either commit the users to the group or cancel.

Technology Being Used:
I'm using Spring in conjunction with iBATIS. For backend database I am using Oracle.

Desired Solution:
What I would like to do is wrap all the activities of the administrator in one big transaction. Mind you that the administration page has many iFrames with their own Spring controllers. When the administrator is satisfied he/she can clicks Apply Changes and the transaction is committed to the database. If he clicks cancel, the transaction is rolled back. I want session level view of the current data in the database. Is this possible with Spring and iBATIS?


I have tried quite a lot of things including using ThreadLocal session variable in my target/manager class but nothing seems to work. If you have an alternative solution that you would like to recommend I’d love to hear it. Essentially what I want is something akin to Hibernates session view. Maybe even user save points? Are save points possible with Spring and iBATIS?

[Colin Sampaleanu]

I would almost say that your best choice is actually Hibernate long running optimistic transactions. That is, the code is running outside of a real database transaction, but a version check on the objects or part of the graph catches optimisitic failures.

Colin

[smccrory]

Maybe this is silly, but why not store the admin's pending changes in the HttpSession until they're ready to click "Commit"? Is it really critical that you wrap their entire use case in a database transaction?

[irbouho]

IMHO, saving the changes in the HttpSession is an appropriate solution for "less-complex" scenarios.
This approach has some limitations; among others:
1. If the end-user has to update tens of Objects, you need to cache the entire objects graph (maybe not all the objects) in memory.
2. The underlying layer (Services and DAO) should be aware of the existance of such a duplication. I means, when you run a new query to read some data from the database, you must check, all the time, if the objets returned by your persistance layer have not been updated in your cache.
3. Concurency implementation may be very difficult to implement.