Problem with customer identification

[Roman Traze]

My update method is

void updateRecord(long recNo, String[] data) throws RecordNotFoundException; 

and now I see that there is a new method for new projects:

void updateRecord(long recNo, String[] data, long lockCookie) throws RecordNotFoundException;  

I am not knowing how to identify the customer, since my date is singleton class, and my method does not receive the parameter lockCookie, I will disapprove if I miss a way to identify the customer?

It's no use I spend a LONG generated on the client and assign a variable in the Date class, as being a singleton class, you might find that a client assign a value and then assign a different client, so the first value has been lost. I'm confused.

[K. Tsang]

There should only be one update() method in the Sun's provided interface, either with or without the lockCookie. If your's do not have the lockCookie, then nothing to worry about. If have lockCookie, what is your current approach to identify that customers have the same lockCookie.

There are several threads about lockCookie in the SCJD forum you can reference.

[Roman Traze]

K. Tsang wrote:There should only be one update() method in the Sun's provided interface, either with or without the lockCookie. If your's do not have the lockCookie, then nothing to worry about. If have lockCookie, what is your current approach to identify that customers have the same lockCookie.

There are several threads about lockCookie in the SCJD forum you can reference.

My interface has this method update(long recNo, String[] data) without cookie, then what you are saying that in my case I do not have to worry about identify the customer who placed the block? I will not be reproached for not implementing anything about it?

[Roel De Nijs]

Hi Roman,

If you not identify the client who is locking a record, I think you will fail automatically. Because the scenario "clientA locks record 1, clientB updates record 1 and clientC unlocks record 1" is against the interface you must implement. Making sure a record is only updated/deleted by the client that owns the lock is part of the assignment.

If you have a lockCookie in your interface, client identification is very easy (just use lockCookie value). If you don't have lockCookie in your interface (like you) you will have to find another way to uniquely identify your client: a possibility is implementing the RMI Factory Pattern (like described in Andrew's book).

Kind regards,
Roel