aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes URLyBird: how to calculate clientId Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "URLyBird: how to calculate clientId" Watch "URLyBird: how to calculate clientId" New topic
Author

URLyBird: how to calculate clientId

Colin Yates
Ranch Hand

Joined: Dec 16, 2004
Posts: 31
All,

The URLyBird Data.lock() method states:

"Locks a record so that it can only be updated or deleted by this client...."

How *on Earth* are we supposed to implement this so it knows which client you are? Assuming (incorrectly) that RMI gives you a unique way to determine the client, it would still mean having an RMI enabled class and non-RMI enabled class.

I did think about using the strategy pattern (is that the right one) to determine the client's id, and have the RMI server give out a new id to each client. The question is then how does the Strategy implementation work?

Has anybody just ignored this "client specific" requirement and passed?

Col
Paul Bourdeaux
Ranch Hand

Joined: May 24, 2004
Posts: 783
Ignoring it would probably be a spectacularly bad idea...

What is the method signature for lock in the provided interface? Here is mine:When a client locks a record, a cookie is returned to the client. This cookie must be used to update or unlock the record. You can generate the cookie however you wish, most use the Random class, although some use the current time in millisecs. You just need to ensure that the cookie is unique to the client requesting it.
[ March 04, 2005: Message edited by: Paul Bourdeaux ]

“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook
Colin Yates
Ranch Hand

Joined: Dec 16, 2004
Posts: 31
Hi Paul,

Unfortunately your solution won't work.

The criteria isn't that the *cookie* is the same as returned by unlock, but the *client* is the same.

Imagine, you lock recordA, and get cookie xyz, you ring me up, tell me what xyz is, I can then connect to your server using the appropriate cookie. the cookie is the same, but the client is different.

See what I mean
Paul Bourdeaux
Ranch Hand

Joined: May 24, 2004
Posts: 783
Actually, this is a tried and true solution for many who have passed. Perhaps I am not explaining myself correctly. Here are a couple of good links that have already dealt with this subject. Or you can search the forum for "lock cookie" and you will find 200+.

Lock Cookie
Locking without cookies
Colin Yates
Ranch Hand

Joined: Dec 16, 2004
Posts: 31
Thanks Paul,

The second link (http://www.coderanch.com/t/185817/java-developer-SCJD/certification/locking-without-cookies) contains some excellent comments made by Andrew which seems to support my concerns, and also provides an answer.

Just to be clear, are you saying it doesn't matter that the cookie could come from a different client as long as it is the same cookie that the server has associated with that record? i.e.:

clientA locks recordA and gets cookie1
clientB updates recordA with cookie1
recordA is updated

And you know for definate that people have passed with this approach Maybe my understanding of English is incorrect, but I do not see how that is compatible with "Locks a record so it can only be updated by this *client*"

Thanks Paul.
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Hi Colin,

There seem to be (at least) two different lock mechanisms in the interfaces, one with a cookie and one without. I had the one without and successfully used the Data reference solution that Andrew describes in the second thread (after Andrew had convinced me that using the Thread ID was a bad idea, thanks Andrew!).

If your interface specifies a cookie though, I would go with Paul's suggestion.

Your scenario of clients passing their cookie on to other clients seems a bit too academic to me. If you told your neighbour your bank card code, the ATM would give her the money...
I guess that if the clients did this, you can consider them to be one client network, so effectively one client: problem solved!

Frans.
[ March 04, 2005: Message edited by: Frans Janssen ]

SCJP 1.4, SCJD
Colin Yates
Ranch Hand

Joined: Dec 16, 2004
Posts: 31
Frans,

Apologies, I thought I had specified the methods

They are:
// Locks a record so that it can only be updated or delted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated or delted. etc.
public long lock(int recNo);

So returning the cookie isn't a problem, it is making sure that only the client who called lock for any given record can call unlock for the same record.

Maybe I am going too far with this and the "client specific" thing doesn't need to be implemented, so if clientA happens to know the cookie that clientB has for recordA then clientA *can* do things with recordA.

Even if I follow Andrews advice and create a new dedicated object per client, what happens if that object (because it is a remote object) times out? Another one would be created and all the previous locks would be orphaned.....
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Originally posted by Colin Yates:
Even if I follow Andrews advice and create a new dedicated object per client, what happens if that object (because it is a remote object) times out? Another one would be created and all the previous locks would be orphaned.....


It won't time out, unless the connection is lost somehow (the remote lease is extended every so many minutes). I would interpret "client" as "session" and not require cookies to survive inbetween sessions.

But since your interface specifies a cookie, I would not bother with the Data reference solution at all and use a counter, randomizer or something along that line to generate cookie values.

Frans.
Colin Yates
Ranch Hand

Joined: Dec 16, 2004
Posts: 31
Frans,

I am still not sure how that will prevent clientB using clientA's cookie!

The scenario of clientA gets cookie123 for recordA, clientB somehow magically guesses that recordA's lock is cookie123 and is then clientB is free to update recordA!

Based on everyone's replies, it seems pretty safe to drop the "specific client" restriction and just ensure that the same cookie value is used.

How have other URLyBird people resolved this client specific problem?

Col
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Originally posted by Colin Yates:
The scenario of clientA gets cookie123 for recordA, clientB somehow magically guesses that recordA's lock is cookie123 and is then clientB is free to update recordA!


Well, chances are about 1 in 16,000,000,000,000,000,000 (no kidding!), so I wouldn't worry about it.

How have other URLyBird people resolved this client specific problem?


Sorry, can't help you there.

Frans.
Colin Yates
Ranch Hand

Joined: Dec 16, 2004
Posts: 31
lol

Thanks Frans, and Paul
[ March 04, 2005: Message edited by: Colin Yates ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: URLyBird: how to calculate clientId