Multiple updates
-
Does anyone know this? If I have a dataset as an application-scoped object, can I use C#'s
lock()command on a datatable to make sure that no two users update the table at the same time? It makes sense that I can, being essentially the same as threading, but I can't find confirmation anywhere. Paul -
Does anyone know this? If I have a dataset as an application-scoped object, can I use C#'s
lock()command on a datatable to make sure that no two users update the table at the same time? It makes sense that I can, being essentially the same as threading, but I can't find confirmation anywhere. PaulWhy not just use transaction processing? The database knows what it can thread together and what it can not. (They are very smart)
-
Why not just use transaction processing? The database knows what it can thread together and what it can not. (They are very smart)
Jason McBurney wrote: Why not just use transaction processing? Because it's not that simple. If two users are updating the same table, it's possible that the first user will call for an update while the other is still editing a record. Or in another scenario, it's possible that two users can do an update and then check for the same "everyone is done here" condition and it become true for both of them instead of only one. I want to lock someone out from editing a table completely while any other user is in the middle of processing the same table. In the worst case, I can do this by having a bunch of flags, also in the Application scope. But if lock() works then there's no need to do that. I suspect I might have to run some tests. Paul
-
Jason McBurney wrote: Why not just use transaction processing? Because it's not that simple. If two users are updating the same table, it's possible that the first user will call for an update while the other is still editing a record. Or in another scenario, it's possible that two users can do an update and then check for the same "everyone is done here" condition and it become true for both of them instead of only one. I want to lock someone out from editing a table completely while any other user is in the middle of processing the same table. In the worst case, I can do this by having a bunch of flags, also in the Application scope. But if lock() works then there's no need to do that. I suspect I might have to run some tests. Paul
Isn't that what the 2PL locking algrithum is all about. I am almost sure that the database will deal with this correctly.
-
Isn't that what the 2PL locking algrithum is all about. I am almost sure that the database will deal with this correctly.
Hi Jason, The problem is that all the data is in a DataSet in the Application and I'm using DataAdapters to run any updates made in the page. There's no way that the database can have any idea what I'm doing until I run the updates. By then it's too late. I may be missing something here (I hope so!) but I don't think so. Paul
-
Hi Jason, The problem is that all the data is in a DataSet in the Application and I'm using DataAdapters to run any updates made in the page. There's no way that the database can have any idea what I'm doing until I run the updates. By then it's too late. I may be missing something here (I hope so!) but I don't think so. Paul
... From your other posts, I am assuming that you are editing the data, and not the schema of the database. Additionally this issue you are facing is exactally how the dissconnected ADO classes are designed to work (or So the Micro$oft peps claim) Use the force young Riley, run your test and I think you will find that the solution will be resolved with ADO correctly. Even if two individuals do grab the same row R and edit it. Alice will change R to C Bob will change R to B Then At compleation the row needs to be either B or C. Thus giving you this effect Alice writes Bob Writes Alice Refreshes (and sees row B) if this order of events you feel this is wrong then there needs to be database level locks ( for your application). These locks would tel bob's application that row R is not modifible at this time because it is "checked out" by Alice.
-
... From your other posts, I am assuming that you are editing the data, and not the schema of the database. Additionally this issue you are facing is exactally how the dissconnected ADO classes are designed to work (or So the Micro$oft peps claim) Use the force young Riley, run your test and I think you will find that the solution will be resolved with ADO correctly. Even if two individuals do grab the same row R and edit it. Alice will change R to C Bob will change R to B Then At compleation the row needs to be either B or C. Thus giving you this effect Alice writes Bob Writes Alice Refreshes (and sees row B) if this order of events you feel this is wrong then there needs to be database level locks ( for your application). These locks would tel bob's application that row R is not modifible at this time because it is "checked out" by Alice.
If you're right, Jason, I'm going to be a very impressed and happy camper. I'll give this some heavy testing later in the week. Cheers. Paul