URLyBird 1.2.1 - read for update

[Krzysiek Hycnar]

Hi all,

I'm revising my design at the moment, actually the code is finished and documented, but I still have some doubts.

I guess all of you who implemented this, faced a similar "read for update" problem. You must implement it somehow if you want to avoid booking a room that has already been booked for someone else.

I'd like to find out what are/were your approaches to that issue.

I decided, that I won't allow to read a record that has been locked (to avoid dirty reads), but on the other hand I must read the locked record somehow to make sure that it has not been booked yet.

To workaround this, the Data class maintains a map of cookie to thread names, so when I read a record and detect that it is locked, the current thread name is compared to the name of the thread that locked this record. If the two names are equal I don't make the thread wait, and just let it read the record fields.

Isn't it to restrictive?? That introduces an obvious constraint - the lock and the readRecord (the readRecord call made to check if the record is free for booking) methods of the DBAccess must be called from within the same thread while booking a particular record.

Will appreciate any suggestions as well as constructive critique

Cheers
Krzysiek
[ October 05, 2005: Message edited by: Krzysiek Hycnar ]

[Oricio Ocle]

Hello Krzysiek,

avoid booking a room that has already been booked for someone else....
I'd like to find out what are/were your approaches to that issue.

I implement a business layer with book and unbook methods.
All services are accessed through a facade.
These methods are the only used by the gui updating the db.

I won't allow to read a record that has been locked

it doesn't solve the problem.
Remember that client view of the data could not be upToDate.
You have to implement these restrictions serverside.

... Data class maintains a map of cookie to thread names...

I think your going the wrong way. Try to make your datalayer as independent from client layer as possible.
This could be hard to mantain, and hard to understand.
My position respect my assignment is fullfil the requirements and not more the simplest way.
Hope this could help you

[Thomas Bigbee]

I believe that the requirements state that you can assume that at most there will be only one person in the database at a time, I also believe the requirments also stated that is a record was locked, you were to wait until it was unlocked, and consume no CPU Cycles until then, however, with that said, you bring up a good point.

Typically you will be dealing with detached views of data. Think of it like this. On Ebay, you enter your bid 10 seconds before the bidding is over, you get a message back telling you that you are currently the highest bidder, you refresh the browser, only to find that you have lost.

The only way around this would be to hold a lock on the record, which is a bad idea for a number of reasons.

In the project you will be dealing with a detached view of a record, I don't think that there would be a very likely chance that somehow a record would be locked at the same time you are trying to save (update to the db) it, on the other hand, I think it is very likely that you may try to update a record that has already been updated.

Typically applications or frameworks (like Hibernate, etc...) handle this with versioning, (reading a version/update counter, etc...). You are not allowed to modify the db, so, the only way to handle versioning is to, lock the record for update and check the current record values against the original detached view of the data, if the match, great, if they don't, not so great.

I suggested this before (and am doing it in my own project) and it was derided, by those who obviously know more, however, using versioning would take care of your concerns, and also provide a more robust and correct application.