Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Best Practice for Concurrency Conflict Resolution?
 

Pages: 1
LLBLGen Pro Runtime Framework
Best Practice for Concurrency Conflict Resolution?
Page:1/1 

  Print all messages in this thread  
Poster Message
Emmanuel
User



Location:
Ottawa, Canada
Joined on:
13-Jan-2006 23:14:31
Posted:
167 posts
# Posted on: 28-Jun-2016 19:19:13.  
What is the best way to resolve concurrency conflicts when using LLBLGen (v5 against a SQL Server database)?

I wrote a test app and I see that an ORMOutOfSyncException is thrown. To be able to present the user with a list of entities and fields in their graph to be saved that conflict with server versions, how should I proceed? Specifically:

1) What is the best way to determine which entities in the graph to be saved conflict with the server? I see a lot of information in the ORMOutOfSyncException but don't know how to use it.

2) What is the best way, once I determine which in-memory entities are either a) out of sync, or b) no longer exist in the database.

3) For the entities which are out of sync (2)a), above), what is the best way to determine which fields are out of sync and what their differences are?

4) I added timestamp fields to all of my entities. How do I tell LLBLGen to use this to quickly determine if an entity being saved might be out of sync?

Thanks!
  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14588 posts
# Posted on: 28-Jun-2016 23:48:45.  
4) Best way is to implement the IConcurrencyPredicateFactory, please check Concurrecny Control

1) Using the above you shall receive ORMConcurrencyException, which has a property "EntityWhichFailed".

2) What is the best way to do what? you didn't specify.
I assume informing the user, so it's a BL/UI matter.

3) Fetch the entity again to a different object and do the comparison.


  Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.