Forums Register Login

Determining who is locking/unlocking a record

+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
 

//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
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
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
Time is the best teacher, but unfortunately, it kills all of its students - Robin Williams. tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 599 times.
Similar Threads
record lock&unlock
LockManager Implementation
Lock/Unlock - same thread?
testing locks.
B&S no lock cookies
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 23:10:29.