if you are using RMI (as I am doing) you cannot rely on thread-id.
As far as I know RMI does not guarantee that subsequent requests from the same remote client are processed by the same thread in the server.
RMI is using thread-pooling. At the server site a number of threads are hanging around in a pool (having a party
- which means they are alive
- the whole time the server is running!). If a request is commin' in one of them is grabbed from the pool (lets say its Fred) to do something useful. If Fred is finished he's returned to the pool. If a further request is commin' in another thread may be grabbed from the pool (maybe because Fred is currently busied) to do the task. Ok. I just want to be funny ... erm.
The thing is: When a specific thread at a client is making subsequent requests at the server you cannot be sure that all requests are done by the same thread at the server. Threrefore, using an id of the thread is a risky and not recommendable solution.
!!! If anything I said before is incorrect someone must correct me !!!
This is very important when you dealing with hanging locks (caused by a crashed remote client). Detecting a crashed client does not work (in RMI) via checking the server-threads alive state (use instead the Unreferenced interface!). This is discussed in other threads in this forum.
The locking is primarily needed in the remote scenario to make sure that different remote clients don't access (in a modifying way) the same record concurrently.
If everything is running in the same VM (stand alone situation!) you don't need cookies. You only have to make sure that only one thread at a time is (write)accessing a record (maybe sync them on the record number).
Because I am using RMI for networking I experienced that it is no good to rely on threads directly. I am trying to sync them in some way but I'll avoid to identify them at any time in my code.
I am working hard on a solution for this problem.