Dave Tolls wrote:When an update is sent for a row, the current value in the db is compared with the value from the client and rejected if they're not the same.
So any UPDATE or DELETE has a clause checking that.
Paul Clapham wrote:In many cases the approach taken is to ignore the possibility. After all, in most businesses you aren't likely to have two different users responsible for the same business entity (whatever a row in your table means) and so the problem is unlikely to occur.
John Astralidis wrote:
What I want to "fix" is this senario...
The client-program presents the DB data in a scrollable JTable.
Two different clients running on different PCs can edit simultanuesly the same record. The 1st client deletes the record while the 2nd client updates it.
No error or SQL exception happens here, and the record is deleted.
Ron McLeod wrote:Is this any different than buying a book through Amazon and before you conplete your transaction another shopper has purchased the last one in-stock? Or booking a hotel room on-line and the last room gets reserved before you are done. The backend is able to detect these types of use-cases/scenarios, and inform the shopper that the action that they were trying to perform could not be completed - book no longer in stock, requested room type not longer available.
Paul Clapham wrote:There may be facilities in the database which help you to do whatever it you end up deciding to do. For example MySQL can select rows and put a lock on them such that other users can only read those rows. This sort of thing sounds promising but you have to be careful using it. For example what happens when the first user locks a set of records and then goes for lunch (or on holiday) before deciding what do do with those records? Other users are left fuming.
John Astralidis wrote:
I just want to inform the user that the record he/she tried to update does no longer exist.
Consider Paul's rocket mass heater. |