if you synchronize the methods (or finer grained synchronization if you must) then only one thread can access the file at a time. So there is no problem with concurrant access because there isn't - it's done one at a time. As long as you honour record locks, you should be fine.
nb. this only works if you have something common to synchronize around. If you're using multiple instances of the data class, you might have to lock/synchronize on a shared instance of something else.
The record locking requirement ensures that one thread can lock, read, write, unlock without any other thread being able to update that record while it owns the lock. This doesn't mean that other threads can't read anything or update other records. [ July 12, 2006: Message edited by: Peter MacMillan ]
posted 14 years ago
Thanks for the prompt reply.
There are two issues, one thing is the database record locking mechanism, the second issue is the code synchronization.
Now, from the point of view of the locking mechanism, I must obtain a lock on a record before I can modify it.
When a "client" locks a record, it gets a cookie, which is like a ticket that guarantees that client can alter the record while his ticket is valid.
When I want to modify a record I must deliver to the database the record number and this cookie number (the ticket).
Therefore, if the ticket is valid I allow this client to do a modification on the database file.
However, while this client is doing this modification, another client could be reading the exact same record. As reading does not require a cookie, the record is not enforced to be locked before the reading operation.
Now, Peter, you suggest to synchronize the code. Nevertheless that would have an unbearable impact on the database. Because if I syncrhonize the readRecord() method and the updateRecord() method. Only one of them could be executed at the time for all the clients.
Then, this synchronization would make the record locking mechanism useless. Because only one client at the time could be reading or modifying the database. And the idea is that more than one client can modify the database simultaneously as long as the change is on a different record.
I was talking about an isolation level mechanism. Something that guarantees that while one record is being read or updated, no other transactions can read or modify the record. Even transactions of the same client.
I am just testing an idea right now. I created a Set containing the records currently on executing transactions. At the beginning of every transaction I call a beginTransaction() which adds the record to synchronized Set.
If any other operation(like read operation) happens while the record is being updated, then, the second transaction waits until the first transaction ends.
This would be synchronization at the transaction level, when transactions operate on the same record.
This way I will make sure that a read operation will not be performed until any previous updated operation has completed.
Once the transaction is completed I call an endTrasaction() method which removes the record from the Set and notifies all other waiting transactions on the record to resume their execution.
Then an update on record 32, turns a flag on the synchronized Set, while the flag is on, a read operation will wait, until the flag is turned of.
When the update operation finishes, it turns the flag off and notifies the read operation to resume. The read operation then turns the flag on, making any other update or read transaction wait until it finishes.
I would like, also, to come up with an idea for two read operations on the same record do not exclude each other, but only read and update operations on the same record.
Thanks again for your feedback. I will appreciate any further comments on this regard. [ July 12, 2006: Message edited by: Edwin Dalorzo ]