• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

Problem with customer identification

 
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.
 
Bartender
Posts: 3648
16
Mac OS X Firefox Browser 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?
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • 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
 
What's gotten into you? Could it be this tiny ad?
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic