I mean, you could still implement it as they require, but if you already guarantee a database level lock, then the record level lock is completely useless. It would be just a waste of time. Do you not think this may affect your score?
We should use the lock mechanism for both update and delete (create is not really an issue). That is a good idea but we would then end up with dirty reads.
Basically, I have also tried to come up with a solution where reading and writing takes place on the record level but has Alexander stated this seems to be currently not possible.
Alexander, the way this lock approach works is not at record level, though.
This means that if 5 clients asked the read record for records 1,2,3,4 and 5. And a 6th client asked the write record for record 6 at that time, then this 6th client willing to write his record will have to wait until the other 5 read operations have finished. Right?
Also, if three clients want to write different records. Let's say 8,9,10. The third client will have to wait until the other two have finished to get the write lock.
I hope I have not misunderstood you. At any rate, I have the impression that, unless you implement this at record level, this could be a performance issue. What do you think, Alexander?
With this design, you are simply preventing that two threads read a record simultaneously, which is unnecessary.
Now if the data class or FileAccess are singletons then you will have a single RAF object whether it be static or not.
I didn't try copying the data to every GUI and updating it there. I created the Data object as a singleton and use that to update the database. The server is the only object allowed to update the database.
The GUI just displays the recent view of the records form the last communication with the server.