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

my confusions in FBN

 
Gerald Kou
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't understand why to use the lock/unlock method in Data.java and why to use lockmanager.
I want every client get a remote singlton Data class and use it to access file.
When the action of booking flight is occured,we can use method book(), as below:
public synchronized void book(..) {
getRecord(..);
...
modify(..);
...
}
As the method getRecord() and modify() is also synchronized methods,I think it is thread safe
when I use a singleton class of Data to access db,db in server side.
what's the lockmanager's role? And why needs clientid? all the clients can get the singleton Data
to access db.If one client blocked by another client's access, it will wait untill notify. So
lockmanager's fuction is not required. It only creates some messages for the client which is
blocked in accessing db ? or it has other profits?
the upper opinions are right? If I'm wrong,please tell me where my thinking was poor! Thanks
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Gerald
Is your book() method on the server or on the client side?
If it is on the client side, then you cannot guarantee that another client wont be running at the same time, and perform it's modify between your getRecord() and your modify(). It is only the individual client that is working atomically, not the client - server combination.
If it is on the server side, then you are right - you may not need the lock and unlock methods for the way you are implementing it.
However the problems I see with this are:
  • I think you have the statment in your instructions: You are required to implement the criteriaFind(String), lock(int) and unlock(int) methods. So you have to implement lock and unlock anway.
  • I think you have the statment in your instructions: The client program [...] should include a class that implements the same public methods as the suncertify.db.Data class. Therefore the modify, lock and unlock methods must be available to clients that other programmers may write, and users would expect them to work in a standard manner. (If you do implement lock, modify, etc as RMI methods, then why would you add work for yourself by creating a book() method?)
  • I believe that locking should be client side (for extensibility if nothing else). Let's say a later requirement is to enable two flights to be booked, but if one cannot be honoured then you do not want to book the other (I can give an example of where this could be the case if you like). You could implement this client side by locking both records, verifying seats are available, then if both are OK, book both, and then unlock both. Without locking being available client side, you would have to have some way of doing one booking, then attempting the second booking and if it fails, undo the first booking.
    what's the lockmanager's role?

    The lockmanager handles the locking and unlocking of records.
    You might move it away from Data class because you want to have Data class only concerned with accessing Data, and having a seperate class handling locking and unlocking (this is also better for extensibility: consider if you later had to handle deadlocks - this could fit into a lock manager quite well, but if it was added to the Data class, then the Data class might become quite large and unwieldy).
    It can also be useful if you want to associate client ID's with locks - you cannot pass the client ID to the lock method in Data class without changing the lock methods signature. But you could have a lock method in your lock manager which accepts a client ID as a parameter (and presumably then calls the lock method in the Data class).
    And why needs clientid?

    It is one way to meet the requirement: If an attempt is made to unlock a record that has not been locked by this connection, then no action is be taken.
    Regards, Andrew
  •  
    Damian Ryan
    Ranch Hand
    Posts: 117
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Let's say a later requirement is to enable two flights to be booked, but if one cannot be honoured then you do not want to book the other (I can give an example of where this could be the case if you like). You could implement this client side by locking both records, verifying seats are available, then if both are OK, book both, and then unlock both.

    I would strongly recommend not allowing clients to book more than one record at a time, because that way potential deadlock lies.
    One of the assumptions I made (and explicity stated in my design choices) was that clients were only allowed to lock one entity at a time (and this is enforced on the server side) because this is far and away the simplest way to prevent deadlocks from occurring (and remember, simplicity is a key feature the assessors are looking for). I got 100% for record locking/unlocking.
    I fully endorse what Andrew said about making the lock and unlock methods available to the client. I think there is no other way to reasonably interpret Sun's instruction that The client program [...] should include a class that implements the same public methods as the suncertify.db.Data class.
     
    Gerald Kou
    Greenhorn
    Posts: 14
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    ok! I got a lot!
    I'll realized lock/unlock as requirement said!
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic