• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

dealing with lock lost - URLyBird

 
Fernando Franzini
Ranch Hand
Posts: 489
2
Java Spring Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Folks

My assignment say :

Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.

So I implemented lock properly (at least I hope so ) with wait(), notify() and another stuff....and I've decided ignore completely everthink about managed lock lost...I mean that I dont care if this will happen......I just will document in my choices.txt....cause the assignment dont say nothing about that.....
So...someone have some opinion ? Or submit the assignment with this option ? It's ok ?
Another questions is about RMI....I've decide use it....so.....if I dont care about 'lost lock' I dont need implement RMIFactory (like Monkhouse book explained about) to managed thread and identify threads owner about lock bla bla bla......? I'm confused
Regards.
 
Michael Matthee
Greenhorn
Posts: 3
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fernando,

I'm not quite sure what you mean with a lost lock.
If I understand correctly, you mean the lock is lost in transit from server to client or vice versa?

In that case, it all depends on the implementation you chose.
You could either use:

  • RMI Factory (every worker thread implements the Unreferenced interface,
    with the unreferenced method called sometime after a disconnect occurs)


  • Sockets (receive an exception whenever the client disconnects)


  • Ignore lock ownership all together and implement the following sequence in
    your services layer: E.g. an update call would be, lock() update() unlock()


  • I chose to call the lock and unlock methods within the services layer.
    However, I still used an RMI Factory to separate it from other connection logic.
    (E.g the company could decide to use web services, sockets or something else in the future).

    The factory pattern should be applied whenever there's a need for it,
    not because you only want to identify a lock's owner.

    If you don't need to identify a lock's owner, you might still want to implement an RMI factory. Your choice.

    The second part of your question: Ignoring a lost lock all together....
    Well ... i'll agree with you on that one. The logic to cater for an abrupt disconnection from a client,
    seems a bit out of scope in my opinion.

     
    Fernando Franzini
    Ranch Hand
    Posts: 489
    2
    Java Spring Ubuntu
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I'm not quite sure what you mean with a lost lock.

    I mean that client dont matter how (call direct or use service layer or whatever) lock one record and somenthing happen that interrupting process and so this record end up blocked forerver in server.
    If I remember.....Monhouse book justified the use of RMIFactory to create one object per connection and identify owner lock....
    I've choice RMI and Service Layers...but I'll ignored this "lock lost"......so i'm little bit confuse about all this....I need think better about this stuff.
     
    Roberto Perillo
    Bartender
    Posts: 2271
    3
    Eclipse IDE Java Spring
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Howdy, Fernando!

    I mean that client dont matter how (call direct or use service layer or whatever) lock one record and somenthing happen that interrupting process and so this record end up blocked forerver in server.


    Well, in my case, since I chose to have a fat client, it means that there's a possibility of the client calling lock() on the server and the client crashing, which would cause the record being locked forever. I justified that that happening was nearly impossible, so I didn't bother about it. So, as long as you justify way, it's ok. Ah, and also, call notifyAll() instead of notify()
     
    Fernando Franzini
    Ranch Hand
    Posts: 489
    2
    Java Spring Ubuntu
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    call notifyAll() instead of notify()

    I did....thanks anyway for tips
    Look Roberto....I'm used RMI + ServiceLayer...so is Thin Client..right ? There is possibilities that client crash and lost some lock record ?
     
    Roberto Perillo
    Bartender
    Posts: 2271
    3
    Eclipse IDE Java Spring
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Fernando Franzini wrote:I'm used RMI + ServiceLayer...so is Thin Client..right ?


    Hum... it depends. It depends on which side the business logic is. If it is on the client side, then you have a fat client. If it is on the server side, then you have a thin client.
    Take a look at this interesting discussion that went on some time ago. I think it might be helpful!
     
    Fernando Franzini
    Ranch Hand
    Posts: 489
    2
    Java Spring Ubuntu
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I already read this thread and it help a lot !!
    In my case...is "on the server side".....e.g. the client just receive RMI proxy reference and call methods by remote interface and all processing is being done in server.
     
    Roel De Nijs
    Sheriff
    Posts: 9105
    75
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Fernando,

    If your business service (with the findRooms and bookRoom methods) is at the server side (that's how I did it), you have clearly a thin client.

    Kind regards,
    Roel
     
    Roberto Perillo
    Bartender
    Posts: 2271
    3
    Eclipse IDE Java Spring
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Fernando Franzini wrote:In my case...is "on the server side".....e.g. the client just receive RMI proxy reference and call methods by remote interface and all processing is being done in server.


    Including the business logic? If so, then you got a thin client!
     
    Adriano Nobre Oliveira
    Greenhorn
    Posts: 6
    Java Linux Mac
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Fernando Franzini wrote:Hi Folks

    My assignment say :

    Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.

    So I implemented lock properly (at least I hope so ) with wait(), notify() and another stuff....and I've decided ignore completely everthink about managed lock lost...I mean that I dont care if this will happen......I just will document in my choices.txt....cause the assignment dont say nothing about that.....
    So...someone have some opinion ? Or submit the assignment with this option ? It's ok ?
    Another questions is about RMI....I've decide use it....so.....if I dont care about 'lost lock' I dont need implement RMIFactory (like Monkhouse book explained about) to managed thread and identify threads owner about lock bla bla bla......? I'm confused
    Regards.


    Hey Fernando,

    I was having the same question when I was implementing my "LockManager" class. What I ended up doing is implementing a time-out on the locks, i.e. if a client requested the lock they would have, say, 5 minutes to do their work and release the lock, otherwise the lock on the record would become available again.

    My "LockManager" with time-outs works (JUnit tested), it's neat and all that. The downside though, is this time-out mechanism added extra complexity to my code and if, by any reason, a client takes too long to complete an operation that requires a lock (because the network is too slow or the user starts an operation and goes for a coffee ), the lock will be lost when the client tries to "commit" the operation and the user would get an error message or something.

    So, after re-reading the specs and weighting the pros and cons, I decided to do what many people suggested here and go with the server-side business layer handling the locks. In other words, the business layer (which is assumed to "live real close" to the data access layer, ie. no network between the two or, even better,same JVM) would provide atomic operations to the clients. For example, the business layer would expose a "book room" operation which would do "lock" - "update" - "unlock" (sorry I'm stealing this example from someone else, it's a pretty good example though). Therefore, if the client "dies", "hangs" or "freezes" after the request is initiated, there will be no "lost locks", since it's all handled on the server side. Now, if the business layer dies in the midst of processing a request... well, then chances are the data access layer died as well and all server components will have to be re-initialized (so, no lost locks because we start "clean").

    Cheers,

    Adriano.
     
    Fernando Franzini
    Ranch Hand
    Posts: 489
    2
    Java Spring Ubuntu
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Adriano

    Therefore, if the client "dies", "hangs" or "freezes" after the request is initiated, there will be no "lost locks", since it's all handled on the server side. Now, if the business layer dies in the midst of processing a request... well, then chances are the data access layer died as well and all server components will have to be re-initialized (so, no lost locks because we start "clean").


    Thanks for comments....this is exactly what I did
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic