I've been doing a bit of code review, writing javadoc documentation, etc.
and I just have some minor doubts about cookie generation.
The locking methods in my interface look this way:
I am using a thin client approach and my Network Server through RMI just
exports 2 business logic methods book() and searchRooms().
My current approach of generating the cookie in the lock method is:
I think I've seen some comments recently about perhaps using a different approach with
the current Thread id, something like:
Will it be OK to use the latter? I am just double checking.
I think it looks more straightforward, cleaner and less overhead than using the random number.
I think in the Monkhouse book this is also mentioned and If I understood the topic correctly Monkhouse
says using the Thread id doesn't work when you use a fat client which is NOT my case.
The API for Thread getId() says:
Returns the identifier of this Thread. The thread ID is a positive long number generated when this thread was created. The thread ID is unique and remains unchanged during its lifetime. When a thread is terminated, this thread ID may be reused.
I'd think since all the processing is done on the server side, using the Thread id is not a problem.
I also agree that the best approach to identify a client in the thin client scenario is the Thread's id.
In the thick client scenario, the System.currentTimeMillis() or new Random().nextLong() can also be used.
lockCookie generation is done in the Data class, so shouldn't the implementation of your Data class keep working regardless of the choice for a fat/thin client? Let say I want to reuse your Data class, but because of your implementation I'm stuck to a thin client.
Carlos Morillo wrote:That's why I am posting to clarify and double check but now you are seeding more doubts into my head!
Why not just use System.nanoTime();? That's what I used to generate a unique client identification id. I argumented in my choices.txt that this gives a reasonable uniqueness for now (and can be enhanced in the future)
Carlos Morillo wrote:This is the first time I see you and Roberto have a different point of view!
We had also a very different approach: he implemented a fat client and I chose for the easier thin client approach. But maybe if he would take the scjd again (and he only needs 2 days for it ) he would go for the thin client too.
Roberto Perillo wrote:the Thread's id or System.nanoTime() would be pretty much the same (they would uniquely identify a client).
That's true, but with the thread-id you are stuck with a thin client approach, so the Data class could not be reused in another application (with a fat client) and I don't think the implementation of Data class should have such consequences.
And happy Easter to both of you (and all other ranchers)!
Hum... I think these scenarios are going a little to far. In my opinion, I think the choice of how you identify a client is intimately connected to the signature of the lock() and unlock() methods, and this also suggests the choice of thin or thick client. If your lock() method returns a value, then you can choose to return System.nanoTime() or new Random().nextLong() or System.currentTimeMillis(), because this value can be either returned to the client side and sent again to the server when calling the unlock() method or returned to the bookRoom() method on the server side. But, if the lock() method does not return a value, the easiest approach is to go for the thin client and use the Thread's ID to identify the client. If the lock() method does not return any value, I think the Thread ID might be more effective.
It depends on which interface your implementing (Your assignment)
Some people don't have a cookie defined as part of their interface method signature, thus they need to identify the client to use that for locking.
In your case you can use the generated cookie. No need to track clients.
I'm not sure about using a sequential number though.
I thought the sequential cookie number was ok because the methods which deal with the cookie number are all synchronized. So only one thread can query / update it at a time. I've run Roberto's DataClassTest on it with no problems and unit tested it so I hope it is ok. Though there is still that worry that there some rarely-occuring non-deterministic behaviour going on plauging me...
I had an interface without the lockCookie and I chose a thin client approach. I generated an id (just System.nanoTime()) which is used for client identification (client-side). The book-method in my business service has also this id as parameter, which is used to identify the client when locking, updating and unlocking.
I could have decided not to generate this clientId client-side, but at the server (in my business-method). Again I could use System.nanoTime() as id. I could also have used a sequential id, but then I had to generate this from a synchronized block (because many threads/clients can access the book method simultaneously).
If Roberto's test class runs fine (without running forever that is), your output shows concurrent access to your Data class (not always lock/update/unlock by threadX, but also other threads waiting to lock a specific record) and you can increment the loop counter to 1000 (or 10000) you'll be just fine (certainly if you reuse existing record numbers, because record 1 is continuously recreated and UpdateRecord1Thread and DeleteRecord1Thread will be continuously compete for record 1). Just document your decisions in choices.txt and you'll get a perfect score for the locking section
I'm feeling more confident now. I've run Roberto's class with 100,000 iterations with no locking occuring and I adapted it to have another thread "UpdateRandomRecordThread" and still no locking occurs. I do not re-use record numbers though, firstly because I couldn't get it to work and secondly because I decided that since a record could be marked as deleted in the file, then maybe the "other application" mentioned used this when generating its reports. Both this decision and how I did the locking are in choices.txt.
Hopefully I'll get this delivered soon. I think all it needs is more testing to make me confident. It'd sure help if I wasn't job hunting at the same time though...