• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Determining who is locking/unlocking a record

 
Brian Blignaut
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys,
How do you determine who is locking/unlocking a record? I don't believe that using the current thread is valid, and also using the client IP is also flawed? I implemented it using the current thread and found that the case occurs when the client locks a record and then waits a while, that the client thread is no longer the same, hence he cannot unlock the record. Any ideas?
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Indeed. The RMI specification states that A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread. The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. There are some differences of opinion about the exegesis of this particular verse (Hi Max ), but for me it simply means that you should not make any assumptions whatsoever about the identity of the thread that will handle your method call.
Search the forum for the words "Connection" or "RMI Factory" and you'll get more hints than a dog has fleas.
- Peter
[ January 24, 2003: Message edited by: Peter den Haan ]
 
Brian Blignaut
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From most of the replies I find it seems that there is no 100% sure way of locking without modifying the method signature? Am I correct in stating this? By this I mean that the current thread won't work, and using RemoteServer.getClientHost is also not guaranteed to be unique?
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But there is. If you use an RMI Factory to give each client its own Connection object (implementing DataInterface) to talk to, you can use the Connection object itself as the client identifier.
Again, have a trawl through this group -- you will find many posts on this topic.
- Peter
 
walid aly
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i am having a unique remote refrence for each client connecting to server
but still the method lock in class data can not access this refrence
public void lock (int x)
{
//this will always refer to the current data object which will be always the same
}
how can this be solved without changing the signature of the lockmethod
thanks
walid
 
Bernhard Woditschka
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
//this will always refer to the current data object which will be always the same

The method could reside in the implementation of the RMI Remote interface which when unique for a client knows who it is (thus knowing the 2nd credential implicitly)
Bern
 
Brian Blignaut
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have considered using my remote interface implementation to store the lock, however this means that the database locking mechanism is incomplete? I think that a better solution would be to modify the lock method signature as in my opinion locking a record is a database function and not a function of the client calling lock. Am I mistaken?
 
Bernhard Woditschka
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As long as you can defend your design I think any solution (almost) can be ok. Just state it in your design document.
I have choosen to extend the data class to add/ modify it's behaviour.
Bern
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic