Depends on what type of operations you want to roll back if the transaction fails. Generally you would need to implement one or more resource managers and enlist them in the transaction in order for it to work.
That's a very non-trivial undertaking, and it might be a sledgehammer where you need tweezers, i.e. you should probably not attempt it (I agree with the commenter who mentions the Memento pattern, that is worth looking into). In short, there is no way to simply "roll back" a method call since the changes that it makes might involve different types of resources (memory, filesystems, web services, etc.).
I think it's fraught with all sorts of logical difficulties as well, like should the transaction roll back just the changes performed by your method or should it also attempt to roll back changes performed by other methods called by your method? How would you enforce the ACID properties of the transaction? You would essentially have to stop any other threads from accessing the same memory locations during the transaction to prevent dirty reads, etc. Relational Databases are able to do this because they can strictly control which transactions can access what data and when. Whereas in a single process, when all the threads share the same address space, it is much more difficult.
If you're only interested in reversing memory operations, you should know that at one point MS was considering including Software Transactional Memory (STM) as part of the .NET Framework, but those plans were abandoned due to its difficulties. However, there's a very old MSDN article that tried to implement some similar functionality (it provides a Transactional<T>
type for transactional access to values in memory). I've never seen this used in actual code though.
It might make an interesting research project. For anything else, bottom line though is don't do it. ;-)