Transaction that spans multiple requests

[abthere]

Hello,
is there a standard way to implement a database transaction that spans multiple requests? I know that multiple DSRequests can be executed within the same transactional context when all of them are sent in a single request to the server, but is it possible to do the same across multiple requests? We’re trying to find a way to implement essentially a single depth undo functionality when user can enter “edit” mode, perform number of changes and then decide whether to commit all of them or discard.

[Isomorphic]

From your description it sounds like the best approach might be to perform your "batching" on the client side rather than doing this on the server.
Not sure what UI you're talking about. The ListGrid of course supports built in "autoSaveEdits:false" mode - in which it builds up a set of local edits which a user can choose to submit (or not) as a batch, so if you're talking about just grid editing, this will give you what you want with no extra coding.
(Check out the "Batch Editing" sample to see this in action)
This can also be achieved at a DataSource level, using the "FacadeDataSource" pattern. Essentially you create a dataSource which inherits from your standard server-backed dataSource which handles update requests in a special way - (by applying changes client-side only, and storing the requests in a queue), then have a method to submit all queued requests to the server in a single RPC transaction.

Hope this helps!
Regards
Isomorphic Software

[abthere]

Thank you very much for the helpful pointers. Our most challenging screen involves a TreeGrid that supports drag reparent backed by a datasource with primary key being a sequence. User can also use the context menu to add/edit and delete items. Add and Update screens are implemented as DynamicForm backed by the same datasource. It sounds like "FacadeDataSource" would cover update and delete scenarios, but add would still be problematic because of dynamic loading of the tree nodes and server generated primary keys.
Our application is somewhat unusual in a sense that we only need to support a single user, so scalability is not a concern. We can afford to lock a database connection for as long as necessary. I’m wondering if manually creating an instance of DSTransaction and then storing it in the session would be the right way to achieve a transaction that includes multiple RPC requests?

[Isomorphic]

That approach definitely won't work, and even for a single-user application we wouldn't recommend holding open a transaction across multiple HTTP requests, in part because of what happens if errors occur.

We would recommend tracking the uncommitted changes either client-side in a data structure or server-side in a database table. Which is easier comes down to details of the allowed operations and schema.

In both cases this is essentially the facade pattern - you are creating a DataSource that sends responses as though certain changes had already been saved.

Bear in mind, if you need help with this, parts of the work could qualify as a Feature Sponsorship (either new features, or just a new sample for the Showcase that shows an example of how this could be solved).