Conor Allen

Hmm...
Is there any guarentee that the server side object that they use is not resued by other clients? i.e. does rmi view server side rmi objects as stateless?
Conor

My feeling is that you just ignore them ... if it is not in the spec .... don't do it ...
Anyone else?

[This message has been edited by Conor Allen (edited June 08, 2001).]

OR ....
Once a full db lock is granted then block in the lock method until all outstanding locks have been released ....

hmmm ....
You could use the thread name to hold the id of the current client as long as you set it for each method invocation ... is that not what you did to make the id of the client available to the lock/unlock method .... or did you use a static variable in some class .... still the question asked how to id the currently executing thread ...
To quote the original post ....
I am testing to see how many different threads get spawned when clients make requests. How do a get the thread id of the current thread?
Conor

[This message has been edited by Conor Allen (edited June 07, 2001).]
[This message has been edited by Conor Allen (edited June 07, 2001).]

With respect,
You can use that method to identify the thread that is running ... and I am aware that RMI makes no guarentees about a client always using the same thread, but that was not the question asked .... the question was how to identify that executing thread
Conor

Hi,
I was wondering what software this site used for the discussion forum.
Thanks in advance
Conor

The static method of the Thread class currentThread() returns a reference to the currently executing thread. You can use the toString method to return a String which will contain the objects class type and its address in memory(i.e. java.lang.Thread@asdf22132). You can use this string to identify the thread.
Conor

Two things:
Quite a number of people have not identified the client at all ... just relied on the clients behaving ... i.e. adhering to a lock/read/modify/unlock constraint. If this is the case you never need to identify the client because the lock method will block any thread that requests a lock untill that lock has been released. I'm not sure what I'm gonna do yet ... I've implemented the locking without the client being identified. Identifying the client would make things more complicated. The requirements say 'keep it simple'.
Other people have altered the signature of the lock/unlock methods to accept a token which represents the locker. This seems like a simple solution of the client definitely meends to be identified.
Aleksey ... what did you do to get the client id from the 'CustomSocketFactory'? Is this not a compley solution to the question?
Anyway, just my thoughts
Conor
P.S. Guess that was three things ....
[This message has been edited by Conor Allen (edited June 07, 2001).]
[This message has been edited by Conor Allen (edited June 07, 2001).]

I would have a look at some of the locking strategies suggested in this discussion group ... It might give you some food for thought.
Conor

To be honest, I am not sure how good an idea it is. It does mean that you can provide a remote interface to the Data class which can then be reused for any database which needs that type of functionality.
Clear as mud??

Thanks for your reply ...
Conor

Still noy 100% clear here - The flight broker was the remote object (from rmi perspective) and it just had methods like bookFlight() and findFlights() and did not provide access to the actual public methods of the Data class?
If this was the case did this not break the requirement to provide all the public methods of the Data class to the client?
Hopefully this is not a stupid question .....
Conor

Hi,
Congratulations. Quick question ... did you attempt to track the clients, and if not how did you justify that decision?
Cheers
Conor

Douglas,
Did your FlightBroker class implement the public methods of the Data class or did it use them to perform the logical operations on the Data class?
Regards
Conor

If the data class implements the remote interface then the client just uses an object which implements that interface .... whether it is local or remote is irrelevant
Regards
Conor