SCJP 1.4, SCJD
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 ]
SCJP 1.4<br />SCJD 1.4
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.
SCJP 1.4, SCJD
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.
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 Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
SCJP 1.4, SCJD
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
|