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?
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 ]
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?
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
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
//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
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?
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 by:autobot
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