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

Modification while reading?

 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sun provided me an interface which contains the following two methods:



This implies that reading a record do not require previous lock on it.

Hence, I could be reading a record which is currently being modified by another client. The read then could return partially updated information.

What do you do with these kind of drawbacks?
Do you simply document them or do you try to address the issue?
Are you providing some sort of transaction isolation at the record level?

Any comments on this will be most helpful!

Thanks in adavance,
Edwin Dalorzo.
[ July 12, 2006: Message edited by: Edwin Dalorzo ]
 
Peter MacMillan
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Peter

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 ]
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are confusing the reasons for locking a record and synchronising code.

One is to avoid several threads accessing a piece of code at the same time, the other to allow a client to reserve a record for itself for modification.
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not at all. I understand they are completely diffirent things.

My point simply is that you have to do something to avoid a client to read a record while other is updating it.

It has to do little with the locking mechanism and much with the code synchronization.

I just would like to know in what way, you guys, addressed this issues.
[ July 12, 2006: Message edited by: Edwin Dalorzo ]
 
Thirumurugan Mylrajan
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

This issue of "Dirty Read" has been discussed before and I feel its too much of work to implement this "not required feature".

When you are doing a update/delete, lock the record and read it once again to check that it has not been modified. It if has been modified just bail out.

Hope this helps.

Thanks.
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Edwin, if you synchronise access to the actual file you will never have that scenario.
 
Roy Mallard
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If your "Record" objects are immutable you will not have to worry about a record containing partially updated fields.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic