I have been in the architecture state of mind lately and before I even try to go there, I thought I would ping this forum.

Basically, I want to have a web user control that starts a COM+ transaction, and put the object with the original object context into the Session object. The idea is that other COM+ objects in other web user controls (rendered in the same session) can enlist in the original transaction started in the first web user control.

In a windows forms application, this is no problem. But, in ASP.NET when the page is done posting back, the objects are gone, unless they are in the cache or session, etc. etc.

Ultimately, if the object is still in the session when the session terminates, we roll back the transaction and all nested transactions, but if the user makes it to the end and decides to "Save" the data, we attempt a commit, and roll back on error.

So, has anyone done this or heard of this, or have I just gone completely mad?

Why would you need a COM+ transaction for this?

Why can't you just store your data objects (be they datasets or entity collections or whatever) in the session, updating your user's data in your cached data objects as you go then finally persisting the data back to the datastore at the end of the process?

This way your "transaction" only exists at the final stage of the process.

One of the basic rules I always learned when doing transactions is: do never, ever interrupt a transaction with user-input activity.

Also, I agree with netclectic, I don't think you'll need a transaction here, as there is only activity at the end of the chain of screens. So if the user stops half-way, you don't have to roll back anything, as the user hasn't made any persistent calls yet.

netclectic wrote:

Why would you need a COM+ transaction for this?

Why can't you just store your data objects (be they datasets or entity collections or whatever) in the session, updating your user's data in your cached data objects as you go then finally persisting the data back to the datastore at the end of the process?

This way your "transaction" only exists at the final stage of the process.

Great point, sometimes I over complicate matters. Both of your suggestions go back to general good programming techniques, i.e. begin the transaction as late as possible and finish it as soon as possible.

Thanks again.