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

URLyBird Locking

 
Alan W Morgan
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey guys,

I'm having a bad head day so I was hoping ye might be able to help me with my thought process.

I am thinking about how to go about booking a room.
The three methods I am thinking about are :

public void update(int recNo, String[] data, long lockCookie)
throws RecordNotFoundException, SecurityException;

public long lock(int recNo) throws RecordNotFoundException;

public void unlock(int recNo, long cookie)
throws RecordNotFoundException, SecurityException;

So my thinking goes as follows :
1. The User hits book on a selected record.
2. I need to lock record, update with customer number if not already booked and then unlock record.
3. So I have a book method on DatabaseAdapter which calls lock, then calls update passing lockCookie returned, then calls unlock.
4. If lock is called on record already locked I wait on it.
5. unlock calls notifyAll() for any clients waiting on lock


Am I on the right track or way off ?

Thanks,
Alan.
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Alan W Morgan:
1. The User hits book on a selected record.
2. I need to lock record, update with customer number if not already booked and then unlock record.
3. So I have a book method on DatabaseAdapter which calls lock, then calls update passing lockCookie returned, then calls unlock.
4. If lock is called on record already locked I wait on it.
5. unlock calls notifyAll() for any clients waiting on lock


Hi Alan,

You are on the right track. I would change one thing though:

I would not have update() check if the room is already booked. Update() should be a generic database function, that has no knowledge of the business. So it should not know that the data in the records is about rooms and how it can see if a room is booked. You should use read() to read the record and then check if the room is booked. So:

1. lock
2. read; if booked unlock and abort
3. update
4. unlock

Frans.
 
Alan W Morgan
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Frans,

Thats makes sense alright.
At least I'm on the right track.

Alan.
 
Alan W Morgan
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually another question just occured to me.

Where should my book method reside ?

Is book Business Logic ?.
If so would it be better off in the Controller/Business logic layer ?.

So book knows it has to lock, check availability, update and unlock all of which are generic Data actions.
However does this mean then that book is on the client side and I end up making mutiple client-server calls as opposed to just one when book was in my DatabaseAdapter ?
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Alan W Morgan:
So book knows it has to lock, check availability, update and unlock all of which are generic Data actions.
However does this mean then that book is on the client side and I end up making mutiple client-server calls as opposed to just one when book was in my DatabaseAdapter ?

Book is indeed a business action as far as I am concerned and it has to do these things you mention.

This does not necessarily mean that book has to be client-side. Because that depends on if you choose a thin-client or a fat client architecture. You can probably find numerous discussions about these on this forum. My personal opinion is that the assignment hints you to make a fat client (which has the business functionality on the client side), but not everybody agrees and numerous people have passed with a thin client architecture.

Frans.
 
Alan W Morgan
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks again Frans - fat client sounds like it will do me.

One last question -
The requirements say that my data access class must be called Data.java and must implement an interface DB.

My first thought was that Data would be a singleton (I have lockCookie in my
methods) that would control access to my db file.
Then I would need to synchronize certain methods on this class.
Is this ok to do or does it compromise the interface ?

Then I was thinking that Data would contain a Database class that would control access to the db file and Data would simply pass call thru to contained Database.

The second method is closer to the example in the Haibi et al book but is it overkill and is the first solution sufficient.

Thoughts ?
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Then I would need to synchronize certain methods on this class.
Is this ok to do or does it compromise the interface ?

That will be OK, because you are not modifying the interface.

Then I was thinking that Data would contain a Database class that would control access to the db file and Data would simply pass call thru to contained Database.

The second method is closer to the example in the Haibi et al book but is it overkill and is the first solution sufficient.

I did not read the Habibi book, but I think either way will be fine. But you don't need to make a pass-through only to avoid synchronizations on your Data methods.

Frans.
[ April 22, 2005: Message edited by: Frans Janssen ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic