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
|
Originally, I had incorrectly assumed (or misread) that the entirety of a UnitOfWork was transactional... but upon further investigation, http://www.mindscapehq.com/documentation/lightspeed/Basic-Operations/Transactions, it appears that ONLY the SaveChanges operation is transactional... We are noticing many deadlock issues in our application, and other issues where I was relying on SQL locking (blocking) to aid with business logic... i.e. get entities with status = "queued", set status = "processing"... to make them thread safe... (the next thread to run that method wouldn't get the "queued" entities, and therefore wouldn't duplicate effort). code example:
FYI: Our DB is set to "READ COMMITTED SNAPSHOT" isolation, which I understand to mean, SQL does more work in tempdb, however, reads don't lock/block. This seems to be Microsoft's recommendation. Since I assumed (incorrectly) that all UnitOfWork activity was transactional, what would the impact be if I wrapped all my UnitsOfWork (that modify/call .SaveChanges) each in a transaction to match my assumption to reality? (I'd modify the above as follows:)
|
|
|
Wrapping the UOW in a transaction scope will mean that all calls within the UOW are done within the context of that transaction rather than being implicit transactions for each read followed by a transaction covering the SaveChanges activity. Wrapping the whole set of work in a transaction will mean you see a consistent view of the world and your reads should not be blocking based on that isolation level. I dont think this will solve the concurrency issue though as if you have two concurrent threads reading the notification data and then acting on it there would seem to be plenty of scope for thread A to pick up work and in the meantime thread B comes through and picks up the same work while thread A is acting on it. You have a comment in the code above which doesn't seem to match up to this as the status change will only be reflected after SaveChanges is called (and with the transaction scope involved, only after the transaction is committed).
|
|
|
Your second paragraph makes sense, if I switch back to "Read Committed" isolation (and reads block), it sounds like I would get the functionality I'm expecting. Does that sound right? Or perhaps, is there any way to signal to LightSpeed to use a "Read Committed" transaction and perform the read/update (SaveChanges) back to back. Update: Found this in another thread:
but I'd use ReadCommitted |
|
|
Yes that sounds correct and the code above is what you will want to wrap your read/SaveChanges activity with; alternatively you can use a transaction scope and specify the isolation level there as well.
|
|