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'

Edit
Report