• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Problem with customer identification

 
Roman Traze
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

My update method is


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



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
Bartender
Posts: 3404
13
Android Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 9934
113
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic