Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Concurrent issue which affects ALL algorithms where record IDs are reused

 
Roman Yankin
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Imagine the data file with just one record, which ID == 1
Lets assume that data file is accessed from 2 clients

The following is the sequence of actions that lead to a bug

1) RecordID=1 is deleted from Client A
2) Cliant A creates new record which ID also equals to 1 (IDs are reused)
3) Client B decides to delete RecordID=1 (oops but this record has already changed)

I wonder how did you or would you workaround this problem?
 
Alex Belisle Turcot
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

to me, this is the same case as to when someone modifies a record while another client is trying to modify it too.

The 1st client will succeed. The 2nd one will try but first I would compare the original data from client 2 with the database. If the data do not match I threw a custom exception "RecordOutOfSyncException".

The 2nd client is denied modification access to the record because he does not hold matching data. Of course for this to work, my method's parameters were "recordID, "Original data", "new data".

Regards,
Alex
[ September 07, 2008: Message edited by: Alex Belisle Turcot ]
 
Roman Yankin
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Alex, but obviously you had some wrapper methods. As far as I know none of the methods defined in assignment interface has such parameter as "Original data". Some do not have even "New data" like - DB#delete(int recNo, long cookie) so the solution you have used is only possible if you call DB#delete from some other method
 
Alex Belisle Turcot
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

the assignment requires that you implement the interface. That is one thing.
After that, you will or course create other java classes!!

One of my classes was named "Services". My GUI would go through my Services to deal with my Data class. My "Delete" method in Service.java would first "lock the record", "read" the record, compare the record, grant/refuse access, "delete/modify" the record and then unlock the record.

That is just some high level indication of what I did, not necessary right on target, but gives you an idea.

Regards,
Alex
 
Alex Belisle Turcot
Ranch Hand
Posts: 516
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

just to add to my previous post.. You need to differentiate source code you write to implement Data.java and code you write for specific purpose in your application. You application is using Data.java, but can still provide some additional features.

Data.java does not require you to deny access to a user when his data is "out of sync". This is something I added as an extra layer to help me deal with this possible situation when using my User Interface.

When using Data.java, you can not be sure that the user will always call "lock" first and "unlock" after. My Services.java will make sure that my GUI will always do "lock - delete/modify - unlock".

Also, I find Data.java to be very low level (database access layer). So my Services class would be a more OO layer using more suitable keywords:

bookContractor rather than updateRecord.

I'm sure there are plenty of other way to design this, this is how I did it.

Regards,
Alex
[ September 08, 2008: Message edited by: Alex Belisle Turcot ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic