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
No You cannot. There is no guarantee that RMI will always use the same thread for individual client. THerefore your thread id's may not be correct. The idea I came up with was to use CustomSocketFactory and identify a thread on a client side.
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
With respect. What would be the point of identifying an executing thread? I assume the question was asked in order to identify a client for lock/unlock method. If you cannot reuse the same thread then you cannot identify a client correctly.
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).]
Originally posted by Aleksey Matiychenko: With respect. What would be the point of identifying an executing thread? I assume the question was asked in order to identify a client for lock/unlock method. If you cannot reuse the same thread then you cannot identify a client correctly.
The reason the question was asked was that I was trying to determine the relationship between threads and object instantiation. I had put some code in my server class which counted how many times it got instantiated and was surprised that the answer was only once. Then I wanted to make sure that multi threading was working as it was supposed to with RMI. My FBNServer class merely serves as the interface to the Data class which accesses the file. When constructed, it instantiates the Data object, and my LockManager object. I was surprised when only one copy of FBNServer got instantiated when servicing 10 clients simulatenously. But by logging the mythread.toString information, I could tell that each client had its own thread. But from the evidence, as far as I can tell, each client always comes back using the same thread. But since Sun states that this is not guaranteed, I think that I will make an assumption clients will only access the database using my program, and that the requirement to "keep it simple" overrides the choices of using the custom socket factory, or of modifying the lock, unlock signatures. I think that this issue is probably THE key design choice of the assignment. My belief is that if I document this understanding to the reviewer, they will see that I have thought out the possiblities and made a reasonable decision, and that this flaw can be rectified, but at the detriment of other requirements. There, I am off of my soapbox now. [This message has been edited by Rick Fortier (edited June 07, 2001).]