Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: lock/unlock - how to identify clients without lock cookie

 
Werner Joerling
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello to all,
I studied tons of topics concerning locking here, but I didn't get a real advance.
I have the contractor assignment (Version 2.3.2) and lock/unlock/isLocked
methods without cookies.
As you know the instructions require:
// Locks a record so that it can only be updated or deleted by this client.
// ...
public void lock(int recNo) throws RecordNotFoundException;
Here my implementation of lock

The exists method throws record not found exception if necessary,
the lockedRecords object is a collection holding the locked record numbers,
and my remote service implementation uses only one single data object.
Now my question: How can I achieve, that a client can only access that records it has locked before?
During my search I found a similar solution with a justification like: "My client does not invoke the data object directly.", which leaded to 2-tier vs. 3-tier discussion.
I consider this answer as not acceptable. The data class has to meet the requirement, independant whether a middle tier object is present that behaves well respectively to an implicitely given lock-access-unlock protocol.
Or I found a similar question with an answer like "The data instance could identify the client connection".
I do not understand this answer. How does it work more precisely?
Sincerely
Werner
[ January 24, 2004: Message edited by: Werner Joerling ]
 
joerg joerg
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Werner,
i have made the SCJD exam half a year ago. I had the "Fly By Night" assignment, but there the problem was similar: I had to lock/unlock
DB records for a client, and i had to control which client attempts
an unlock, but there was no reliable way to find out, from which
client the unlock-request originates from, and the required method
signature didn't allow to include some client identifier.
My solution was to change the method signature to include a session-id
that will identify the calling client. I justified this decision
in my "design condiderations" document, and also wrote a lot on
what other solutions i condsidered, and why they were not suitable.
I passed with an overall grade of 87%, for the server part (which
includes the locking mechanism), i got full 100%. So, if you justify
your approach very well, it should be no problem at all.
There was some discussion about that at this time on this board: Some
other people have done it similar, and all they have passed the exam.
Good Luck
Joerg
 
Werner Joerling
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Joerg,
thanks for your advice.
At the moment I'm tending to a 3-tier solution without client identification.(Because I have it ready).
Changes of the signatures are out of the question for me.
Additionally I'm examining if it is possible to reidentify the clients by storing the "Thread.currentThread().getName()" or
"Thread.currentThread().hashCode()" together with the record number.
I doesn't yet know if this works.
Sincerely
Werner
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Joerg Joerg

My solution was to change the method signature to include a session-id
that will identify the calling client. I justified this decision
in my "design condiderations" document, and also wrote a lot on
what other solutions i condsidered, and why they were not suitable.
I passed with an overall grade of 87%, for the server part (which
includes the locking mechanism), i got full 100%. So, if you justify
your approach very well, it should be no problem at all.

I think your idea makes perfect sense! But, I'm too afraid.
Afterall, if someone gave you a method definition, and if left something
out as critical as who "owns" the record, in the real world, there would
not be any "must" conditions: basically, you would not be caught dead
adding complexity to a project simply because somebody left out a
critical parameter to a method.
Maybe I'll argue this? It certainly could be called a "human error" for whoever
defined the method signature. And, also, do not the directions say "make
the solution simple?"
Again, though, I tend to go with the herd, at least for my preliminary design
decisions, to get an idea of "how much it will cost" to use Sun's rediculous
method signatures.
Thanks for your input,
Javini Javono
[ January 25, 2004: Message edited by: Javini Javono ]
 
Leo Tien
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Werner:
The data instance could identify the client connection

This is my design.
In my program, I let every client create a Data instance, and use this to access the db file. In other words, I use multiple Data instance design. My lock's segment like follows:

Additionally I'm examining if it is possible to reidentify the clients by storing the "Thread.currentThread().getName()" or
"Thread.currentThread().hashCode()" together with the record number.

I think use thread to identify a client is too limited. But I cann't make any idea to explain this, perhaps some others can help you.
 
joerg joerg
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Javini Javono,
in my assignments there was a sentence about
"realistically imperfect specifications".
In my justification i cited this sentence and
made the assumption that the method signatures
might be "imperfect".
Regards
Joerg
 
joerg joerg
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Werner,
using threads to identify connections will not work.
The java documentation says, that there is no reliable
relationship between threads and connections.
And you can easily test it for yourself: Just write
some small multithreaded client- and server-program,
and you will see, that different threads occur on the
same connection.
Regards
Joerg
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Werner,
There are 2 simple solutions to uniquely identify connections without relying on Thread references, neither changing Data methods signatures.
The first one is the one Leo described above : using the Data instance as identifier. That's the most used on this forum, I think and it is correct. I didn't use it myself, because I wanted to stuck my design on a single table system.
The other one is making Data delegating his job to another class. In the latter, update, delete, lock and unlock accept an additional parameter representing the connection. Methods signatures in Data remain unchanged, the connection object being passed to Data in its constructor.
Best,
Phil.
 
Bill Robertson
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have you tried something like:
import java.net.InetAddress;
int ID = InetAddress.getLocalHost().hashCode();
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic