• 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Handling Lock/unlock

Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys:
any advice on this would be gratefull.
it is better to make the server handles the lock/unlock, where i am not gonna bother with keeping client reference or id, or a thread timer, or
let each client do lock/unlock where it starts mess everything.
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I suggest you handle the lock/unlock with client id (created by the server), synchronize the lock/unlock process with a LockManager and also synchronized methods in the Data class.
Posts: 17346
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Through use of interfaces, implementation of Remote Objects, one for each client, there is no need to change the lock method signature or the use of server generated client ID's. Search on this forum for Connection Objects. This is the best way to go.
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys,
I know there are totally different solutions on the positions of calling bookSeat() that lock() and unlock() are inside. Both of the solutions have their own advantages.
1. call it at client side follow sun's implication. and it will close to passing exam in theory. but some problem is really there. Record will be locked for ever when clients crashed after calling lock() without call unlock().
2. call it at server side against sun's implication.
but it's more reasonable. it's an atomic solution. avoid to deadlock a record.
Maybe Sun implies us to implement an generic DB server. but Sun is more explicitly tell us to implement an traditional client-server application. For such an application we are not supposed to put all business logic method at client side. We can certainly put some business logic method at server side. Let's say bookSeat() just like a stored procedure we put at server side.
Do you guys think Sun will penish this idea that is not stupid? I really take the second solution mentioned above.
My key question is will I be punished to fail the exam by taking the second solution.
Do you guys know if there are somebody to pass the exam by taking the second solution.
thanks for reply
[ April 08, 2002: Message edited by: Dasong ]
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mark,
Big DUH!! on the unique remote object for me. I totally wasn't thinking that object identity is one of the principles of object orientation. Too many years of procedural programming almost got me on this one. I was trying to implement my locking scheme without regard to server interaction. Without all yours posts on this subject, I probably wouldn't have figured this one out.
Thanks again
Michael Morris
Is that a spider in your hair? Here, threaten it with this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic