• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Using Thread ID for lock owner not safe?

 
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 181
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Hey, I'm supposed to be the guide! Wait up! No fair! You have the tiny ad!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic