In a C# project, I have a (volatile) transactional resource enlisted in a System.Transactions.Transaction.
When a transaction timeout occurs, the rollback is executed in a worker thread: Obviously, the transaction uses a timer and calls a timer callback when the timer elapses (there is very little documentation from MS on this issue). Thus, the implementation of IEnlistmentNotification.Rollback(...) in my transactional resource is called asynchronously.
My question is: How do I handle this? Of course, the rollback code changes the internal state of my resource, e.g. by discarding changes. It seems that I must synchronize all access to this resource. However, the resource is not designed to be thread save. Does anyone have experience with this problem, or is there some kind of "best practice" for this?
views:
582answers:
1
A:
I guess you could lock the resources' rollback methods to make them synchronized, as the rollback would be the odd-case-out and serializing access wouldn't cause too much problem perf-wise...
With IoC, e.g. Windsor, implement IInterceptor and lock around all IResource.Rollback() methods with the interceptor. It's an orthogonal concern, so it should be implemented as one.
Henrik
2010-10-24 20:19:54