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 am having issues getting LightSpeed to work inside a Parallel ForEach loop (see sample code)
Is this due to the data being lazy loaded? How is the best way to handle this situation? Is there a recommended TPL pattern for Lightspeed? |
|
|
Yes, it is due to the data being lazy loaded. A unit of work encapsulates a database connection and should therefore be used from only one thread at a time. The best option in this case is to eager load the OtherTable association. You know you're going to need it for every Document, so you may as well grab it up front. This not only solves the threading problem, it is also more efficient (avoids the n+1 problem). If there are circumstances elsewhere in the program where you want a Document without its OtherTable, then you can make OtherTable conditionally eager-loaded using named aggregates. See the LightSpeed user guide for details. |
|
|
Okay thanks I'll look into the named aggregates. |
|
|
Ivan, would you care to elaborate a little on this TPL situation. What if... the situation were a little more complex. What if inside that Parallel.Foreach I was planning to calculate the Wordcount of the document and then save it? What would your recommendation for UoW management be then? Not that I would ever contemplate doing such a thing as the consequences of opening up a couple hundred thousand DB connections sounds like a recipe for disaster. So here is a different, more realistic, scenario ... My application has a lot of API calls which try to complete their mission and return a response to the client ASAP. Any non-essential activities I like to split out as an asynchronous task. Where I run into problems is the places where an API call launches a couple of background actions: one to send an email (which writes a log entry) and another to update some stats (another set of DB actions), maybe another checks if the customer has exceeded limits imposed on their plan. These things have been intermittently failing in tests because they are all sharing the same UoW which they got from their shared context. I've solved the problem by having each of these background tasks create their own UoW. But I just wondered what the Mindscape wisdom is on such matters... |
|
|
As Ivan previously commented "A unit of work encapsulates a database connection and should therefore be used from only one thread at a time." so you do would want to look a separate UnitOfWork per thread in general to avoid complexity - of course it only scales so far. If you are operating over a set of data where its much better to share this resource which seems fairly sensible in your scenario then you will need to look at managing the concurrency via some locking around the UnitOfWork.
|
|
|
Jeremy you are wise as ever. That makes perfect sense to me. |
|