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
|
hi, a general design question... i've got a windows service which processes jobs (backed against a db table to maintain state) in a multi-threaded manner. (JB knows about this one.) Jobs may run against EntityA or EntityB, where there is a 1-many relationship between them. There is some complicated state maintenance running between the entities (which are essentially a db-backed state machine) so sometimes a child entity will tell its parent to update itself because the child entity has been updated. All very OO. Each service thread picks up a job (which references an entity) and gets its own UOW for the lifetime of the job. The issue is that i am getting the occasional concurrency exception where two threads are each processing a different child entity but which share the same parent entity. Each child entity tells its parent entity to update itself and one of them will fail on commit because the lockversion is out of date. I've turned on optimistic concurrency for these entities for the moment because i want to know when i'm getting concurrency issues wrt updates occuring simultaneously on different threads. A couple of specific updates I've pulled out into a sproc to deal with this concurrency but I'm not sure of the best way to handle the more general entity update commits. Should I just be pushing all parent entity updates through a sproc to control concurrency at the db level rather than in the model? I don't think a multithreaded, multiple UOW service is the right place for using the optimistic concurrency stuff but at the moment it is highlighting nicely that i have some concurrency issues that should be dealt with properly. I've been following the partial properties update threads thinking that could help but i don't think it will as the core problem is that I have multiple threads wanting to update the same property on the same entity - but in different UOW. And because I'm dealing with state in a 1-many relationship I can't just use last-in-wins. And I can't share a long-running UOW between the different threads as it will get stale because there are other processes (eg WCF) which can also update entities. Do you have any suggestions? Are there any obvious facilities in LS that I should be considering/using? thanks |
|
|
If the updates are being made within a UnitOfWork then you are always going to run in the concurrency issue while you checking for this (and there is a concurrency issue) so there is nothing in LightSpeed to work around that - quite the opposite :) It sounds like you need to centralise the update of the Parent entity and make sure it is done serially then you will need to pass this through a stored proc or some other central facility which can manage this in a serial manner. Is this updating an aggregate root value or the like? :)
Jeremy |
|
|
well, sort of. I've basically got state flowing between three entities. EntityA has many EntityB. EntityA also has many EntityC. Updates to EntityA.Status can happen either directly or from EntityC. eg When the Status (property) changes for EntityC, if EntityC is the 'most recent' for EntityA, the property setter will propagate the change to EntityA. When EntityA updates its Status (property), that is propagated through to all EntityB. This could all happen in the same update batch. So the aggregate root is EntityA but the update is initiated through EntityC. The problem I have is that some other process may have updated EntityA.Status in the meantime (because updating EntityC might take a couple of minutes between loading the object graph and updating its Status). Given there are multiple (not just two but many) processes running on multiple machines, each of which could update the aggregate root for a variety of reasons, there doesn't seem to be any other central facility other than the db to control the serial updating of EntityA. It looks like the access method is either table or sprocs-for-all-CRUD, yes? I really only need a sproc for the update method - but i guess it's not possible to specify a sproc only for updates? So am I right in thinking the options are:
cheers |
|