• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: URLyBird Modifying updated record problem

 
Alexei Antipin
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Consider the following scenario:
?Client ?A? tries to modify record ?R? and successfully obtains the lock for this record
?Slightly later, client ?B? tries to modify the same record, tries to obtain the lock, but the record ?R? is currently being modified by ?A?, thus ?B? waits until ?A? releases the lock.
?Client ?A? releases the lock, client ?B? obtains the lock, but the data in the record ?R? now differs from one expected by ?B? at the time it requested for lock. If the application allows such modifications it can lead to unpredictable results, e.g. ?B? can re-book the record ?R? previously booked by ?A?.
This problem was solved by the means of record ?versioning?. Each client (including client in standalone model, but except server GUI) operate with copies of record objects, rather than records themselves. Data model maintains a cached list of records that are displayed by corresponding JTable control. Each record is represented by an instance of DataRow interface. Class, implementing this interface has a member ?version?, that is incremented on each data change, thus if the version of a record in the data model is not the same as the version of the record with the same id on the server, the record was modified outside this particular client.
Database object maintains locking of a record. When database object locks a record it returns a lock cookie that is formed as follows ? lower word is a version of the record, higher one is a value of a counter, incremented with each call to lockRecord method. This technique allows uniqueness of the lock cookie within reasonable number of requests (until Integer does not overflow) as well as record versioning support.
When data model retrieves a lock it uses its versionFromLockCookie to obtain actual version of the record and compares it with local version. These versions must be the same, different versions mean that the record has been modified and the operation on the record should fail.
Any comments?
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Alexei,
I believe this will work.
Just to clarify my understanding: when the client gets a record from the server, they actually get a "DataRow" (or some class that implements DataRow) which includes all the standard fields plus a field for the version number. Then when they lock the record they should get the version number in the lower word of the lock cookie. Is this correct?
I guess in the real world you would have to have additional logic to ensure that if the version number integer overflowed then you would reset it. In the case of this assignment though, it is unlikely to cause a problem since a record should only transit from unbooked to booked, so it is unlikely to go through a large number of versions.
My main concern is that this may be overkill for the assignment. All you need to cater for is whether a record is currently booked or not. So when the client gets the lock on the record, they can re-read that record, and if it has not been booked, then they can book it.
While your concept is more robust, and can handle things like the price having changed, it may be more difficult for a junior programmer to understand. But as long as you document it well, it should certainly work, and you should be able to pass with that design.
Regards, Andrew
 
Alexei Antipin
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Andrew Monkhouse:
Hi Alexei,
Just to clarify my understanding: when the client gets a record from the server, they actually get a "DataRow" (or some class that implements DataRow) which includes all the standard fields plus a field for the version number. Then when they lock the record they should get the version number in the lower word of the lock cookie. Is this correct?


Exactly


I guess in the real world you would have to have additional logic to ensure that if the version number integer overflowed then you would reset it.


In fact even in a real world it is not neccessary because the version itself has a little meaning, it is valuable only in pair with additional word (32bit) that forms a lock cookie. The probability that the lock cookie formed this way for one single record will be the same to allow two
different clients modify the same record is virtually equal to zero.


While your concept is more robust, and can handle things like the price having changed, it may be more difficult for a junior programmer to understand. But as long as you document it well, it should certainly work, and you should be able to pass with that design.


It is surely well documented
Thanks, Alexei.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic