Cookie Generation

[Carlos Morillo]

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:

// Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.
public long lock(int recNo) throws RecordNotFoundException;
// Releases the lock on a record. Cookie must be the cookie
// returned when the record was locked; otherwise throws SecurityException.
public void unlock(int recNo, long cookie)
throws RecordNotFoundException, SecurityException;

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:

long cookie = rand.nextLong() + System.currentTimeMillis();

I think I've seen some comments recently about perhaps using a different approach with
the current Thread id, something like:

long cookie = Thread.currentThread().getId();

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.

[Carlos Morillo]

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]

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.

[Roel De Nijs]

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

[Carlos Morillo]

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]

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]

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:

long cookie = rand.nextLong() + System.currentTimeMillis();

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


Thanks and Happy Easter!

Carlos.

[Roberto Perillo]

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]

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]

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]

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

[Walid Abd Elsalam]

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.

[John McParland]

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]

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]

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