aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes dealing with lock lost - URLyBird Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "dealing with lock lost - URLyBird" Watch "dealing with lock lost - URLyBird" New topic
Author

dealing with lock lost - URLyBird

Fernando Franzini
Ranch Hand

Joined: Jan 09, 2009
Posts: 486
    
    2

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.


Fernando Franzini - Java Blog
Michael Matthee
Greenhorn

Joined: Jun 23, 2009
Posts: 3
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.


    http://flexingcode.blogspot.com/
    Fernando Franzini
    Ranch Hand

    Joined: Jan 09, 2009
    Posts: 486
        
        2

    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

    Joined: Dec 28, 2007
    Posts: 2267
        
        3

    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()


    Cheers, Bob "John Lennon" Perillo
    SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
    Fernando Franzini
    Ranch Hand

    Joined: Jan 09, 2009
    Posts: 486
        
        2

    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

    Joined: Dec 28, 2007
    Posts: 2267
        
        3

    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

    Joined: Jan 09, 2009
    Posts: 486
        
        2

    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
    Bartender

    Joined: Jul 19, 2004
    Posts: 5515
        
      13

    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


    SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
    http://www.javaroe.be/
    Roberto Perillo
    Bartender

    Joined: Dec 28, 2007
    Posts: 2267
        
        3

    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

    Joined: Jul 16, 2006
    Posts: 5

    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.


    SJCP 1.4 & 6.0 | SJCD | OCEJWCD
    Fernando Franzini
    Ranch Hand

    Joined: Jan 09, 2009
    Posts: 486
        
        2

    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
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: dealing with lock lost - URLyBird