I was wondering about having a local RAF instance for each method that accesses the DB, too, but won't it still create a problem when there are too many operations going on? (like, 50 clients calling read() at the same time? I know that some in some systems only 32 file pointers are allowed at a time..)
What happens when you try to create a new RAF instance when there are already too many file pointers in use, thus the system won't allow a new one?
Also, how big of an overhead would be created by creating and closing local RAF instance within the methods?
Now if the data class or FileAccess are singletons then you will have a single RAF object whether it be static or not.
With this design, you are simply preventing that two threads read a record simultaneously, which is unnecessary.
So, when there is only 1 RAF instance, you still have to synchronize the RAF instance, because of the file pointer issue, as you have mentioned. What I'm saying is that this will also solve the logical locking issue. For instance:
client A and client B calls update at record 1 at the same time.
since client A and B both use the RAF instance(and update method is synchronized), only one of the clients can update the record at a given moment. so there is no need to have logical locking implementation. Everything will work fine without the logical locking mechanism. No?
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?
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.
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.