aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Cookie Generation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Cookie Generation" Watch "Cookie Generation" New topic
Author

Cookie Generation

Carlos Morillo
Ranch Hand

Joined: Jun 06, 2009
Posts: 221

Hello Everybody,

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.

Any thoughts? Comments?


Thanks in advance,


Carlos.

SCSA, OCA, SCJP 5.0, SCJD, CCDH, CCAH http://www.linkedin.com/in/carlosamorillo
Carlos Morillo
Ranch Hand

Joined: Jun 06, 2009
Posts: 221

I just was double checking but after some further digging I think it's OK to use the Thread Id in a thin client
after reading this post and in specific Andrew Monkhouse's reply in this thread.
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2266
    
    3

Howdy, champions!

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.


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5406
    
  13

Hi Carlos,

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.

Just my 2 (actually 1) cents (cent)

Kind regards,
Roel


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Carlos Morillo
Ranch Hand

Joined: Jun 06, 2009
Posts: 221

Hi Roel,

You are correct, yes the Data class should continue working regardless of a fat/thin client,
That's why I am posting to clarify and double check but now you are seeding more doubts into my head!


The Thread id is a unique long number so by implementing the lock()/unlock() methods
of the Sun interface I think it is meeting the requirements and so far I think it works.

I just want to double check and make sure I am not missing anything that can
produce an undesirable side effect.

I guess if the Data class were to be used as a fat client perhaps I would need to use a Factory
of the Data object like in the Monkhouse book.

Am I missing something?


Thanks,

Carlos.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5406
    
  13

Hi Carlos,

Carlos Morillo wrote:That's why I am posting to clarify and double check but now you are seeding more doubts into my head!

Oops

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)

Kind regards,
Roel
Carlos Morillo
Ranch Hand

Joined: Jun 06, 2009
Posts: 221

Hi Roel,


I feel relieved now ... Sigh!


I guess what you suggest is similar but certainly a way more accurate timer than using my original approach:



This is the first time I see you and Roberto have a different point of view!


Thanks and Happy Easter!

Carlos.
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2266
    
    3

Carlos Morillo wrote:This is the first time I see you and Roberto have a different point of view!


Hum... if you look closely, we have the same point of view. In the end of the day, the Thread's id or System.nanoTime() would be pretty much the same (they would uniquely identify a client).

Happy Easter, everyone!
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5406
    
  13

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)!

Kind regards,
Roel
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2266
    
    3

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.
John McParland
Ranch Hand

Joined: May 11, 2009
Posts: 92

Hi folks,

err reading this has gotten me worried. I went for a sequential number for my lock cookie and I don't use client IDs anywhere (can't see any need for them).

A sequential number for my lock cookie seems sufficient because lock is synchronized (along with everything else in my Database class, Data is a facade to it).

I just can't think why I need a client ID. The lock, update, unlock all happens on the Server side for me (the business class) so I don't need to track clients.

Have I missed something or am I just too nervous as I'm nearly finished my assignment?

Regards,

John


Passed: SCJP 6 (90%), SCJD 6
Other: Spring training, extensive Swing experience
Walid Abd Elsalam
Greenhorn

Joined: Feb 26, 2010
Posts: 20
Hi John,

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.


SCJP 6 85% - SCWCD 86%
John McParland
Ranch Hand

Joined: May 11, 2009
Posts: 92

Hi,

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...

Regards,

John
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5406
    
  13

Hi John,

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

Kind regards,
Roel
John McParland
Ranch Hand

Joined: May 11, 2009
Posts: 92

Thanks Roel,

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...

Regards,

John

 
Consider Paul's rocket mass heater.
 
subject: Cookie Generation