This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I have a multi-threaded application which I am using a PerThreadUnitOfWorkScope in. After completing a set of work on a thread I'd like to be able to dispose the unit of work in the scope and then reset it to a new unit of work. Right now I can see how to dispose the unit of work (call dispose on the Current or on the unit of work scope base) but I don't see any way to then have the unit of work scope then reset to a new unit of work... right now it will always dish up the now disposed unit which isn't terribly great for the next set of work. I think the ability to tell a unit of work scope to reset to a new unit of work would be a useful feature. |
|
|
Oh, other account. That was from me :D |
|
|
The guidance I always give is, "Don't use PerThreadUnitOfWorkScope." It has other problems which in my view make it unsuitable for multithreaded applications. Given your requirement -- to be able to pull a UOW out of a contextual scope object, but to be able to reset that scope object so it serves up a new UOW next time you ask -- I think your best bet is a custom scope. Something like (not tested, not error-checked): class ResettablePerThreadUnitOfWorkScope<T> : UnitOfWorkScopeBase<T> |
|
|
I have a custom unit of work which has slowly evolved to be almost exactly like that (I have an IResettable interface which my code uses to determine whether that type of unit of work is able to be reset) I think a Reset method on the base unit of work would be useful for other users. It will save them going through the trial and error of creating their own unit of work. |
|
|
While we're talking about unit of work scope, a Disposed event would be useful as well :D In a multithreaded application I'm slightly paranoid about leaving database connections open. Being able to easily attach some logging to an event on the unit of work scope that gets raised when the unit of work is disposed would be very useful. |
|