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
|
Hello, If two users connect to a same database and each of them create a Unit of Work at the same time, what will happen if they both save changes to the same database? For example, one user (user one) deletes a table from the Unit of Work and saves changes, and the other user (user two) adds a record to the same table (which has been deleted by user one) and saves changes. Could you please talk some details about how to deal with these kinds of concurrent issues, such as above? Thanks. |
|
|
|
|
By default its last in wins. We do support optimistic concurrency through the use of a versioning property so updates wont be applied unless the object is of the expected version, this is using the special property called LockVersion which you can apply to your entities. To give you an example, lets say you have User A and B operating against a single table. Lets say the table has 3 existing entities, Ids 1 2 and 3 with a name property. So the initial state would be say: {Id: 1, Name: "Jeremy"}, {2, "Ivan"}, {3, "JD"} 1. User A loads Entity 1 and makes an update to the Name to "Bob" 2. User B loads Entity 1. (Name is "Jeremy" because User A has not flushed yet). 3. User A calls SaveChanges(), the record in the database is now {1, "Bob"} but User B will still have a name of "Jeremy" because it was already loaded in to memory that way. 4. User B changes the name to "Fred" and calls SaveChanges(). The record in the database is now {1, "Fred"} If you were using LockVersion then at Step 4 an exception would be thrown on the SaveChanges() call because LightSpeed would detect that an update had been made to the database while User B was making their changes, you could then catch this and handle appropriately. As an aside, you cannot "drop/delete a table" with LightSpeed. You could however remove all of the entities, but in the scenario you have described above that wouldnt cause a concurrency issue.
Jeremy |
|
|
|
|
As an additional tip, if you're using the designer, you can turn on optimistic concurrency checking by selecting the entity and setting Optimistic Concurrency Checking to True. (To be clear, this doesn't work any differently from what Jeremy describes, it's just a shorthand way of generating the special LockVersion field. So your database table will still need the LockVersion column. (Which the designer will offer to create for you if you use the Update Database command.)) |
|
|
|
