• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

My new way to handle timeout lock

 
Ranch Hand
Posts: 166
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My architecture:
1. 3 tier
2. lockcookie isn't sent to client.
3. lockcookie is based on currentTimeMillis
4. lockcookie is checked to see if there is timeout, whenever a lock happens.
5. This way has been tested and works.
6. "Please let me know if this way works???" Thanks.

GenerateLockCookie


CheckLockCookieTimeOut


LockRecord

[ September 22, 2004: Message edited by: Steve Taiwan ]
 
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This code won't work well, the loop to generate a key will cause very poor performance and is usually viewed as a bad practice. Secondly the wait call will need a maximum time or it could wait forever on a very quiet system.
[ September 22, 2004: Message edited by: peter wooster ]
 
Steve Taiwan
Ranch Hand
Posts: 166
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear Petter.

I check my source code again, and I can't understand why you said it could wait forever. could you tell me why???

This design is not very good. But is it acceptable???

Thank you for your time, Petter.
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Steve Taiwan:
Dear Petter.

I check my source code again, and I can't understand why you said it could wait forever. could you tell me why???

This design is not very good. But is it acceptable???

Thank you for your time, Petter.



If one user had a record locked and all the others were waiting on the wait in lock to get a record, they could wait for ever, unless you specify a timeout in the wait or have some regular notification occurring.

If all the locking is done in the server and locks are never sent over the network this can't happen, but in that case the timed locks don't buy you anything at all, you could just use sequential longs.
 
Steve Taiwan
Ranch Hand
Posts: 166
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear Petter.

But I have checkLockCookieTimeOut(reservedRec) with wait() to check a timeout lock. And my thread is trying to address the problem of "wait forever". So could you please look at my source code again???

My architecture is 3 thier and lockcookie won't be sent to client.

And even in server side, there is still a chance that a dead lock happens between update and lock. Therefore, I try to solve the problem.

Thank you, Petter
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Steve Taiwan:
Dear Petter.

But I have checkLockCookieTimeOut(reservedRec) with wait() to check a timeout lock. And my thread is trying to address the problem of "wait forever". So could you please look at my source code again???

My architecture is 3 thier and lockcookie won't be sent to client.

And even in server side, there is still a chance that a dead lock happens between update and lock. Therefore, I try to solve the problem.

Thank you, Petter



If you don't expose the locking to the client, you don't need to worry about timeouts, your record locking code can be very simple and work perfectly.

If you were exposing the locking to the client, you might need something to recover from orphan locks, I assume that's what this code is supposed to do. On the assumption that it is possible for a lock to be orphaned your code won't work.

In your code you do:

what causes the wait to exit? Something must do a notify or notifyAll on reservedRec. If that doesn't happen, this code will wait forever.
 
Steve Taiwan
Ranch Hand
Posts: 166
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear Petter.

Please let me explain my code as the follows.
And Petter, please be kind to let me know what's wrong in my code. Thanks.

1. Thread A lock RecNo 1.
2. Thread A tries to update RecNo 1 but "fails" due to some error.
3. static HashMap still records that RecNo 1 is locked.
3. An hours passed.
4. Thread B tries to lock RecNo 1 in
while(reservedRec.containsKey(String.valueOf(recNo)))
5. Thread B fails to lock RecNo 1 because HashMap records that RecNo 1 is locked.
6. Thread B goes to wait in
reservedRec.wait();
7. A while
8. "Automatically" Thread B is waken and runs the following code.
checkLockCookieTimeOut(reservedRec);
9. In the block of checkLockCookieTimeOut(reservedRec), timeout limitation is an hour.
The code traverse HashMap to get all LockCookie of time base. Then find out LockCookie
of RecNo1 is timeout when my code compares LockCookie of RecNo1 with CurrentTime.
So checkLockCookieTimeOut(reservedRec) will remove RecNo 1 from HashMap.
10. Thread B goes back to
while(reservedRec.containsKey(String.valueOf(recNo)))
11. Because RecNo 1 is removed by checkLockCookieTimeOut(reservedRec),
RecNo 1 no longer exists in HashMap.
12. while(reservedRec.containsKey(String.valueOf(recNo))) is not executed due to
false returned by containsKey(String.valueOf(recNo)).
13. Thread B can do what he wants to do on RecNo 1.


I read a lot of thread talking about wait and lock. They all do what I did.
try {
reservedRec.wait();
}
Or Petter, what should I do to correct it???
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Steve Taiwan:
8. "Automatically" Thread B is waken and runs the following code.
checkLockCookieTimeOut(reservedRec);



What causes Thread B to awaken? You could specify a timeout in the wait eg.

which would only wait one minute.

All of this is not needed if your locks are all done on the server (thin client model). In that case there should be no error that leaves a record locked. You should unlock in a "finally" statement in each of your business commands.

If you are using the rich client model and the client is doing the locking, you need to clear all locks when a client closes or is open but idle too long. This can be done with SoTimeout on sockets or the RMI lease time.

/peter
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Steve & Peter,

I didn't see anything in the instructions that suggested a timeout was required. And if you do implement a timeout, you will have to change the comments above the lock method to indicate that it will timeout - which to me seems to indicate that you will not be implementing the method the way that Sun envisaged it.

Why do you feel that a timeout is required?

Regards, Andrew
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Andrew Monkhouse:
Hi Steve & Peter,

I didn't see anything in the instructions that suggested a timeout was required. And if you do implement a timeout, you will have to change the comments above the lock method to indicate that it will timeout - which to me seems to indicate that you will not be implementing the method the way that Sun envisaged it.

Why do you feel that a timeout is required?

Regards, Andrew



I agree completely, I don't use any timeout on the wait, but Steve asked how to make his code work. In my code I rely on the network to clean up any orphaned locks since I'm in the rich client camp. Steve appears to be in the thin client camp so he has no need to worry about this at all as long as all his business methods unlock under all circumstances.
/peter
 
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Andrew,

And if you do implement a timeout, you will have to change the comments above the lock method to indicate that it will timeout - which to me seems to indicate that you will not be implementing the method the way that Sun envisaged it.


// Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.


I wonder whether some timeout on locking could make sense in the fat-client model, without breaking the instructions. Not a timeout on waiting for the record to be available for locking, but some timeout to avoid a client keeping a lock for ever.

Of course the RMI lease renewal can be used for the same purpose (unlock locks hold by crashed clients through Unreferenced), but as OOH the default RMI lease value is 10 minutes (a little long to hold a lock, right?) and OTOH the RMI FAQ explains that:

The client will renew each lease when it is halfway expired. If the lease interval is too short, the client will waste a lot of network bandwidth needlessly renewing its lease. If the lease interval is much too short, the client will be unable to renew the lease in time, and the exported object may be deleted as a result.

, some locking-specific additional timeout mechanism seems at least to be defendable.

I started this by "I wonder" on purpose, so take this more as a question than any assertion of mine.

Best regards,

Phil.
[ September 23, 2004: Message edited by: Philippe Maquet ]
 
Steve Taiwan
Ranch Hand
Posts: 166
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear Peter, Andrew and Phil.

Thank you for the comments. I am indeed in Thin Client Camp.
Thank you, Peter, to remind me that I should unlock in "finally" statement.
I am considering if timeout solution is necessary and, Peter, I will let you know my decision later.

And 2 more questions:
1.You said �All of this is not needed if your locks are all done on the server�. Which means �object.wait(60000);� is not necessary when I am in thin client camp???
2.Could you please confirm that if my timeout solution is acceptable???

I think the timeout solution is necessary because a lock mechanism should always go with a timeout solution to prevent from dead lock, no matter what kind of solution you choose. In thin client camp, it might be safe when lockcookie stays in server side and when we always unlock in every �finally� statement. But I am still considering Peter�s opinion about not to implement timeout solution in my project.
[ September 24, 2004: Message edited by: Steve Taiwan ]
 
Andrew Monkhouse
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Phil,

Originally posted by Philippe Maquet:
I wonder whether some timeout on locking could make sense in the fat-client model, without breaking the instructions. Not a timeout on waiting for the record to be available for locking, but some timeout to avoid a client keeping a lock for ever.



That would make sense, however I would argue that it is still beyond the specifications of the assignment. In the real world, we would go to the client and tell them that we think that this is necessary, and it will only cost them 5 additional man days (which they will say is outrageous and we will compromise to something reasonable ). But since we don't have that option, then adding this functionality could result in us doing work that no-one is paying for.

Best regards, Andrew
 
Andrew Monkhouse
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Steve,

Originally posted by Steve Taiwan:
Thank you for the comments. I am indeed in Thin Client Camp.



Sorry to hear that



Originally posted by Steve Taiwan:
I think the timeout solution is necessary because a lock mechanism should always go with a timeout solution to prevent from dead lock, no matter what kind of solution you choose.



In the thin client solution, you are calling one method via RMI, which will call the lock() and unlock() methods itself. That method will complete, even if the client crashes. So for thin clients timeout should not be necessary.

It is only in fat clients that you might want to consider what happens if the client crashes while owning a lock. (You might not though - plenty of people have argued that it is beyond the requirements and they have not been penalised for that decision). If you did decide to consider this, then I personally think that using something like java.rmi.server.Unreferenced or java.util.WeakHashMap to do something if the client crashes would be better than changing the specification for the provided lock() method.

Regards, Andrew
 
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by peter wooster:


Here are some design notes from a student who passed with a high score using a thin client.
Ken Krebs' Design Notes. I have read most of the messages on this topic and still feel thin client is wrong, and couldn't challenge an automatic failure if I got one for doing it. That said, its a neat way to circumvent much of the interesting work in this project. Just be sure to thoroughly document the design choice.

[ September 28, 2004: Message edited by: peter wooster ]




I think the only problem with a thin client is this: do I allow the client to get all the records from a search and then, at the client, to figure out which to display, and which to ignore. Of course this functionality will allow future versions of the client to add different options for create/delete/unbook. I actually could not name one more function this client would need.

Or alternatively, do I handle all the record sieving at the server, so that the client only sees the filtered records. Then, of course, the client is hard to extend, but not that hard.

As for exposing the Data class to the client, I think it introduces unnecessary complexity into the code, and I did not do it. Of course, there are other opinions, which are equally valid.
 
Steve Taiwan
Ranch Hand
Posts: 166
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear all.

As a J2EE programmer, I prefer 3 tier.

I decided to give up time-out method in 3 tier.
But I will document this in my choice.txt.

Thank you, guys, for reading my thread and for giving me so many suggestions.
 
Anton Golovin
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Steven. If you are in the thin-client camp, then a timeout is completely unnecessary. Any business method called will run to completion regardless of the state of the client. It will lock, modify, and unlock. (Then, as it prepares to marchall objects remotely, it will encounter a RemoteException (in the remote code.)

About the thin client design, a more interesting question, I have come to this conclusion: a purely thin client, where the client sees only the bookable records, is not very extensible. It will pass the assignment, and a certificate will be awarded, but in terms of extensibility, it is just not a very good choice. The choice of thin or thick client is a tradeoff between flexibility in business rules and extensibility of client functionality. I realized that as I pondered how the unbookRoom method would work.

There are workarounds around this, such as passing business rules to a thick client at startup, but these things are beyond the scope of the assignment...

Still, as I also implemented a thin client, I should say it works in the scope of the assignment.
[ September 28, 2004: Message edited by: Anton Golovin ]
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Anton Golovin:
Hi, Steven. If you are in the thin-client camp, then a timeout is completely unnecessary. Any business method called will run to completion regardless of the state of the client. It will lock, modify, and unlock. (Then, as it prepares to marchall objects remotely, it will encounter a RemoteException (in the remote code.)

About the thin client design, a more interesting question, I have come to this conclusion: a purely thin client, where the client sees only the bookable records, is not very extensible. It will pass the assignment, and a certificate will be awarded, but in terms of extensibility, it is just not a very good choice. The choice of thin or thick client is a tradeoff between flexibility in business rules and extensibility of client functionality. I realized that as I pondered how the unbookRoom method would work.

There are workarounds around this, such as passing business rules to a thick client at startup, but these things are beyond the scope of the assignment...

Still, as I also implemented a thin client, I should say it works in the scope of the assignment.

[ September 28, 2004: Message edited by: Anton Golovin ]



The debate between thin and rich clients comes down to the issue you mentioned. The thin client is not extensible without making considerable changes to the server. The rich client model exposes all data methods to the business code on the client, and as such fits the requirement for an easily extended client. I used the thin client model on a previous version, but have switched to a rich client.

A true thin client would use a browser, JSP and server, since this is explicitly forbidden, you can't really achieve a thin client or a true 3 tier architechure.
 
Anton Golovin
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mine is done, and I probably will not rework it. Do you think a thin client can pass, though?
[ September 28, 2004: Message edited by: Anton Golovin ]
 
Steve Taiwan
Ranch Hand
Posts: 166
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear Anton

I believe there is a guniea pig for thin client.
Please read this thread.
https://coderanch.com/t/184224/java-developer-SCJD/certification/Should-lock-methods-callable-client

you will be satisfied at this thread and result.
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Steve Taiwan:
Dear Anton

I believe there is a guniea pig for thin client.
Please read this thread.
https://coderanch.com/t/184224/java-developer-SCJD/certification/Should-lock-methods-callable-client

you will be satisfied at this thread and result.



Here are some design notes from a student who passed with a high score using a thin client.
Ken Krebs' Design Notes. I have read most of the messages on this topic and still feel thin client is wrong, and couldn't challenge an automatic failure if I got one for doing it. That said, its a neat way to circumvent much of the interesting work in this project. Just be sure to thoroughly document the design choice.
[ September 28, 2004: Message edited by: peter wooster ]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic