Steve Taiwan<br />SCJP 1.2, SCJD 1.4, SCWCD 1.3, SCBCD 1.3, OCP 8i DBA, SCEA
Steve Taiwan<br />SCJP 1.2, SCJD 1.4, SCWCD 1.3, SCBCD 1.3, OCP 8i DBA, SCEA
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.
Steve Taiwan<br />SCJP 1.2, SCJD 1.4, SCWCD 1.3, SCBCD 1.3, OCP 8i DBA, SCEA
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
Steve Taiwan<br />SCJP 1.2, SCJD 1.4, SCWCD 1.3, SCBCD 1.3, OCP 8i DBA, SCEA
Originally posted by Steve Taiwan:
8. "Automatically" Thread B is waken and runs the following code.
checkLockCookieTimeOut(reservedRec);
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
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
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.
, some locking-specific additional timeout mechanism seems at least to be defendable.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.
Steve Taiwan<br />SCJP 1.2, SCJD 1.4, SCWCD 1.3, SCBCD 1.3, OCP 8i DBA, SCEA
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.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Originally posted by Steve Taiwan:
Thank you for the comments. I am indeed in Thin Client Camp.
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.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
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 ]
Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Steve Taiwan<br />SCJP 1.2, SCJD 1.4, SCWCD 1.3, SCBCD 1.3, OCP 8i DBA, SCEA
Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
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 ]
Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Steve Taiwan<br />SCJP 1.2, SCJD 1.4, SCWCD 1.3, SCBCD 1.3, OCP 8i DBA, SCEA
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.
Consider Paul's rocket mass heater. |