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've looked through the samples and documentation but can't find any examples showing the correct way how to use the PerThreadUnitOfWorkScope object, which may be because its still early and I haven't had my morning coffee yet so I apologize if I've missed something.
I want to use the PerThreadUnitOfWorkScope for a small WPF application.
Thanks in advance.
Stuart
|
|
|
I don't think we have a sample for this (we know we need to get some samples together for WinForms and WPF), but typically you use the PerThreadUnitOfWorkScope with a Repository class (e.g. deriving from RepositoryBase). You can then use the repository as a singleton and let the scope object take care of creating units of work when required -- in this case whenever a new thread does some work with the repository. Does that clarify things or is there something more specific that we need to document / provide a sample for? |
|
|
Is there anything with regards to disposing that i need to think about. A simple code sample would be great :)
|
|
|
If you are using the repository from threads that are short-lived, then your thread function should dispose the UOW before it returns, otherwise you'll leak database connections. (There is a Dispose method on the scope object itself, but looking at the implementation, I'm not convinced it's correct, so I'd advise checking for a UOW and disposing that directly.) Basically each thread is going to get its own UOW instance, and therefore its own database connection, with all the consequences for resource usage, object identity, etc. that this implies. Therefore whether PerThreadUnitOfWorkScope is appropriate to your app will depend on your intended usage pattern. If you have multiple threads operating on the same repository -- e.g. a background thread and the UI thread -- then PerThreadUnitOfWorkScope may not be a good solution because of object identity. If you have lots of short-lived threads then PTUOWS may not be a good solution because of resource management (disposal) considerations. PTUOWS may be more appropriate to partitioned / parallel processing scenarios where each thread is doing its own "batch" of work and the threads only die when the entire app dies. We'll try to put together a code sample for desktop clients and for PTUOWS but we don't have either to hand so this may not happen until we do our next big samples push as part of LightSpeed 3 -- sorry. |
|
|
Thanks Ivan, thats enough to get me going.
|
|