How do I make an in-memory process transactional?

Question

I'm very familiar with using a transaction RDBMS, but how would I make sure that changes made to my in-memory data are rolled back if the transaction fails? What if I'm not even using a database?

Here's a contrived example:

public void TransactionalMethod()
{
    var items = GetListOfItems();

    foreach (var item in items)
    {       
        MethodThatMayThrowException(item);

        item.Processed = true;
    }
}

In my example, I might want the changes made to the items in the list to somehow be rolled back, but how can I accomplish this?

I am aware of "software transactional memory" but don't know much about it and it seems fairly experimental. I'm aware of the concept of "compensatable transactions", too, but that incurs the overhead of writing do/undo code.

Subversion seems to deal with errors updating a working copy by making you run the "cleanup" command.

Any ideas?

UPDATE:
Reed Copsey offers an excellent answer, including:

Work on a copy of data, update original on commit.

This takes my question one level further - what if an error occurs during the commit? We so often think of the commit as an immediate operation, but in reality it may be making many changes to a lot of data. What happens if there are unavoidable things like OutOfMemoryExceptions while the commit is being applied?

On the flipside, if one goes for a rollback option, what happens if there's an exception during the rollback? I understand things like Oracle RDBMS has the concept of rollback segments and UNDO logs and things, but assuming there's no serialisation to disk (where if it isn't serialised to disk it didn't happen, and a crash means you can investigate those logs and recover from it), is this really possible?

UPDATE 2:
An answer from Alex made a good suggestion: namely that one updates a different object, then, the commit phase is simply changing the reference to the current object over to the new object. He went further to suggest that the object you change is effectively a list of the modified objects.

I understand what he's saying (I think), and I want to make the question more complex as a result:

How, given this scenario, do you deal with locking? Imagine you have a list of customers:

var customers = new Dictionary<CustomerKey, Customer>();

Now, you want to make a change to some of those customers, how do you apply those changes without locking and replacing the entire list? For example:

var customerTx = new Dictionary<CustomerKey, Customer>();

foreach (var customer in customers.Values)  
{
    var updatedCust = customer.Clone();     
    customerTx.Add(GetKey(updatedCust), updatedCust);

    if (CalculateRevenueMightThrowException(customer) >= 10000)
    {
        updatedCust.Preferred = true;
    }
}

How do I commit? This (Alex's suggestion) will mean locking all customers while replacing the list reference:

lock (customers)
{
    customers = customerTx;
}

Whereas if I loop through, modifying the reference in the original list, it's not atomic,a and falls foul of the "what if it crashes partway through" problem:

foreach (var kvp in customerTx)
{
    customers[kvp.Key] = kvp.Value;
}

Answer 1

Pretty much every option for doing this requires one of three basic methods:

1. Make a copy of your data before modifications, to revert to a rollback state if aborted.
2. Work on a copy of data, update original on commit.
3. Keep a log of changes to your data, to undo them in the case of an abort.

For example, Software Transactional Memory, which you mentioned, follows the third approach. The nice thing about that is that it can work on the data optimistically, and just throw away the log on a successful commit.

Answer 2

Take a look at the Microsoft Research project, SXM.

From Maurice Herlihy's page, you can download documentation as well as code samples.