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 ]
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
posted 16 years ago
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
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 ]
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.
posted 16 years ago
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
posted 16 years ago
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
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.