Win a copy of 97 Things Every Java Programmer Should Know this week in the Java in General forum!
  • 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 ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

Handling Lock/unlock

 
Greenhorn
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.
------
Thanks.
 
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.
 
ranger
Posts: 17346
11
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.
Mark
 
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.
bookSeat(){
lock();
read();
modify();
unlock();
}
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
Dasong
[ 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
 
I got this tall by not having enough crisco in my diet as a kid. This ad looks like it had plenty of shortening:
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic