Question

I have an application that has many different types of objects that each persist themselves back to the db. This has worked fine so far without transactions and I’m not looking to go hog wild adding them. But there is an occasional need to start a transaction before a whole collection of the objects start updating to ensure that the database is only actually updated if all objects in the collection succeed.

For example, say I have a collection of apples. The command is issued to the collection to update all the apples. [transaction starting should be here] The each apples executes the code to update itself. [transaction commit/rollback should happen here].

The hitch I have is that each update is atomic right now (not explicitly wrapped in a transaction). I could pass an id to each ‘apple’ to identify a transaction that has been stashed in some kind of cache, but then there’s the risk that the cache would be invalidated mid-update and cause an unnecessary problem.

So what’s the best approach to this?

Answer 1

First, I wouldn’t be handling the transactional logic in the page. Write a business class of some sort to do this – a service, a data utility class, something you can abstract away from ASP.Net.

Next, you might look at using the TransactionScope class (in System.Transactions namespace, reference System.Transactions.dll) if you are using a database that can subscribe to distributed transaction like SQL Server.

using(TransactionScope scope = new TransactionScope()) {   SaveObjectOne(); //these are just psuedo-code statements   SaveObjectTwo(); //replace these with your code that saves various objs   SaveObjectThree();   scope.Complete(); //this commits the transaction, unless exception throws } 

TransactionScope implements IDisposable, so when using calls Dispose() the transaction will roll back if Complete() was never called. You do need to enable the Distributed Transaction Coordinator to use TransactionScope.