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
|
Can an entity belong to multiple UnitOfWorks at the same time? Right now I am using one UnitOfWork for my whole application becasue the data is shared across multiple Windows and the windows can filter the data which affects other windows views. Sometimes I only want to save a portion of data giving the user the ability to cancel changes on other windows Another situation is what if I Dispose the unit of work that created the Entities and then when I wanted to save them attach them to a new unit of work and do the save will that work? I am wish to use the UnitOfWork as you designed it but still need the functionality I wish. I keep reading that the UnitOfWork is designed for short actions and it worries me I am using it wrong with One UnitOfWork for my whole app. Any push in the right direction to docs or a quick reply would be much appreciated. |
|
|
Hi MiddleTommy, I'm not sure if this will resolve your problem, but you can create multiple units of work (nested units of work effectively) where you could load an enity in for editing. The only issue I could see with this approach is that if an entity is altered in a nested unit of work and persisted it will not update that same entity if attached to another unit of work (in fact, you would want to be careful as that entity will now have stale data). I will update you on the adding of an entity to a new unit of work shortly - I'll just experiment with that situation. I hope that helps, John-Daniel |
|
|
Hi MiddleTommy, If you have a new entity belonging to a UnitOfWork and then dispose of the unit of work and attach that entity to a new UnitOfWork it will happily persist. You should be able to see that after disposing of a UnitOfWork that the Entity.EntityState remains as EntityState.New so attaching it to a new UnitOfWork means that it will be persisted. I hope that helps, John-Daniel |
|
|
So pretty much it seems that the Enity's are interchangeable between UnitOfWorks so I dont have to keep a unit of work hanging around just because Also it seems OK to have one entity attached to multiple UOW since the status of the enity is stored in the entity and not the UOW or Context please correct me If I misunderstood Thanks for your help
|
|
|
What happens if you are in a transaction and you switch between unit of work? My feeling is that previous work will then either partially committed or rolled back?
Best Regards,
Richard |
|
|
I just recently saw in a debug session that an entity has a reference to one UnitOfWork. I dont know how that effects my multiple UnitofWork per entity theory. It all depends on how the processing(mindscapes code) occurs in the UOW. As for switching UOW in a trasaction. I am not quite sure how you would do that in code. could you post an example so I can test it? |
|
|
Yes, an entity is associated with exactly one unit of work (well, at most one unit of work -- a newly created entity which has not yet been Added has no UOW). And a unit of work is associated with one connection, and any transaction applied to that UOW is effectively applied to that connection. So "what happens" depends on what you mean by "switching between units of work." You can absolutely have multiple units of work in parallel and do separate work on each: IUnitOfWork uow1 = context.CreateUnitOfWork(); (Obviously you should do this only if the two UOWs are logically separate business transactions.) So if this is what you mean then the answer is "nothing." The work on the first UOW remains pending until you dispose the first UOW or commit or roll back the transaction. The two UOWs are separate and independent. If you are talking about an *entity* switching UOW in mid-transaction, i.e. calling uow2.Add(entity) or uow2.Attach(entity) when entity was previously part of uow1 and uow1 was in a transaction: it depends. Any changes to entity that had already been saved through uow1 would remain as part of uow1's pending transaction. Subsequent changes to entity would be saved through uow2. Obviously this could get very messy: effectively you are updating the same database record through two different connections. E.g. if uow1 was inserting entity, and uow2 then tried to update it, uow2 would find (depending on the isolation level) that the entity didn't exist yet in the database (because uow1 hadn't committed) and the update would fail. Or uow2 might write its changes, then uow1 might try to commit the "earlier" version later (with results probably depending on isolation level). LightSpeed does NOT attempt to sort this out for you and we would advise against doing anything like this! Hope this answers your question -- let me know. |
|