aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Using Thread ID for lock owner not safe? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Using Thread ID for lock owner not safe?" Watch "Using Thread ID for lock owner not safe?" New topic
Author

Using Thread ID for lock owner not safe?

Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Hello all,

In my assignment I have been using the Thread ID as an identifier for which client locked a record. This seems to work as I expected, but I saw hints in this forum that the RMI spec does not guarantee an unique Thread for each client. Did anyone pass using Thread ID?

I had already chosen my Data class to be Singleton, so I cannot use the Data reference as an identifier.

I have been contemplating creating a new DataAdapter for each client (now I have only one, because it is linked with the Data class instance), but so far I have not figured out how my Data class can know which Adapter called the method.

My assignment is almost complete, so I am considering the following alternatives:

1) do nothing at all. Document that I did it like this and it tested OK. (Obviously I would like to hear you all say that I should chose this option )

2) un-Singleton my Data class; this can be done, if I instead make the lock collection and parser classes that it uses as singletons. This will require some heavy refactoring though; something I am not really happy with at this stage in my assignment.

3) somehow using the Adapter reference. Does anyone have a hint how my Data class can tell which Adapter class instance called the lock method?

What solution would you suggest me?

Thanks for your ideas,

Frans.

P.S. my lock method is defined as void, so there is no cookie or something else that will identify the lock owner.
[ January 23, 2005: Message edited by: Frans Janssen ]

SCJP 1.4, SCJD
Daniel Simpson
Ranch Hand

Joined: Sep 02, 2004
Posts: 181
Originally posted by Frans Janssen:
Hello all,

In my assignment I have been using the Thread ID as an identifier for which client locked a record. This seems to work as I expected, but I saw hints in this forum that the RMI spec does not guarantee an unique Thread for each client. Did anyone pass using Thread ID?

I had already chosen my Data class to be Singleton, so I cannot use the Data reference as an identifier.

I have been contemplating creating a new DataAdapter for each client (now I have only one, because it is linked with the Data class instance), but so far I have not figured out how my Data class can know which Adapter called the method.

My assignment is almost complete, so I am considering the following alternatives:

1) do nothing at all. Document that I did it like this and it tested OK. (Obviously I would like to hear you all say that I should chose this option )

2) un-Singleton my Data class; this can be done, if I instead make the lock collection and parser classes that it uses as singletons. This will require some heavy refactoring though; something I am not really happy with at this stage in my assignment.

3) somehow using the Adapter reference. Does anyone have a hint how my Data class can tell which Adapter class instance called the lock method?

What solution would you suggest me?

Thanks for your ideas,

Frans.

P.S. my lock method is defined as void, so there is no cookie or something else that will identify the lock owner.

[ January 23, 2005: Message edited by: Frans Janssen ]

My implementation is similar to yours, although mine uses cookies (lock method returns a long). Here was my solution. Every client connected to the same remote proxy and within that, they all shared upon one instance of my Data class. I defined my locking scheme as "meeting halfway between remote and local." I used a HashMap in my LockManager that stored which record was locked and by which thread. I documented that this was effective in local mode but not necessarily in remote mode. To make up for this in remote, I synchronized all of my methods which made it thread safe in remote, but unnecessary overhead in local. This was just my solution, some may disagree or not like it, but I found myself in the same situation as you.


SCJP 1.4<br />SCJD 1.4
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
You can prove for yourself that RMI doesn't guarantee that the same thread will be used. Try this, in your networked client, try to lock a record that another client already has locked. Now from the client that is waiting try to lock another record. If you are using some kind of worker threads to avoid tieing up your GUI, you will observe that the second lock arrives on a different thread at the server.

It's probably a good idea to build a special test client that lets you do things like locking records and leaving them locked and creating and deleting records. Without such a client there are lots of scenarios that you just can't test.
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Originally posted by peter wooster:
You can prove for yourself that RMI doesn't guarantee that the same thread will be used. Try this, in your networked client, try to lock a record that another client already has locked. Now from the client that is waiting try to lock another record. If you are using some kind of worker threads to avoid tieing up your GUI, you will observe that the second lock arrives on a different thread at the server.

It's probably a good idea to build a special test client that lets you do things like locking records and leaving them locked and creating and deleting records. Without such a client there are lots of scenarios that you just can't test.


Peter,

Thanks for your reply. I made my client single-threaded, so I could not directly create this situation. But I added a multi-threaded test case to my test client (I already had one ) and indeed I observe that at the server's side different thread IDs for a single client emerge.

Although I might get away by claiming that my clients will never put themselves in such a situation, I think this makes my alternative 1 too risky for submittal.

Frans.
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Frans Janssen:

Peter,

Thanks for your reply. I made my client single-threaded, so I could not directly create this situation. But I added a multi-threaded test case to my test client (I already had one ) and indeed I observe that at the server's side different thread IDs for a single client emerge.

Although I might get away by claiming that my clients will never put themselves in such a situation, I think this makes my alternative 1 too risky for submittal.

Frans.


You're welcome, one more piece of advice though.

You really shouldn't make your client single threaded, if you do you can get stuck in situations where the client is waiting for a lock and the user wants to exit and can't because the GUI is hung up. A frequently used rule with GUI's is that no network I/O should ever occur on the Event Dispatch Thread.

I use seperate threads for the network actions, with a busy flag that prevents multiple booking commands, but still allows the user to shutdown properly.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11460
    
  94

Hi Frans

In my assignment I have been using the Thread ID as an identifier for which client locked a record. This seems to work as I expected, but I saw hints in this forum that the RMI spec does not guarantee an unique Thread for each client.


The RMI specification is quite explicit that you cannot rely on thread behavior at all. So you cannot rely on two clients getting different threads (they may get the same thread), likewise you cannot rely on one client using the same thread for two subsequent method calls (it may get a new thread or may use a thread that was previously used by another client.

Here is some simple code that demonstrates some of these issues:



When I ran this, I saw the following output (your output may, of course, differ):



See those lines I highlighted? Client 0 used three different threads on the server, showing that you cannot rely on which thread will be used. Likewise, near the end of the run, both client 0 and client 1 were using the same thread number (although not simultaneously).

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Thanks for all your replies. I am totally convinced now that I cannot use the Thread ID as a client identifier. I am now refactoring my software such that each client will have its own Data class instance and I will use the instance reference as the client identifier.

Peter, I agree in general that one should not block the UI thread. For a real-life application I would definitely choose a multi-threaded solution. However, I am not sure though that I will change it for this assignment, because it will make the code far more complex and I am not sure if I will be doing more than will be required for the assignment.

Frans.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Using Thread ID for lock owner not safe?