Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Contactor: Query on interface methods

 
Manoj Gundawar
Ranch Hand
Posts: 169
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I have been provided interface methods with declarations like:

public void delete(int recNo, long lockCookie)
public void update(int recNo, String[] data, long lockCookie)
and Unlock as follows:
// 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)
What these cookie are ? I guess this is some kind of timestamp. Do I need to implement this functionality? I am planning to implement these methods as is, but not to use the cookie at all.
I think I dont need it, it is not possible in my application for others to unlock the record locked by someone else.
I have created a lock object (which at present just has the record no)
and put that in a vector. (one for all clients)
If this record no is in that vector, it means it is locked.
So at no point, I see the use of cookie.
Can I choose to not use this method parameter?
Detail reply is awaited.
Thanks,
Manoj
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What these cookie are ?
Think of them as a security measure, to ensure that only the client that locked a record will be able to update, delete, or unlock it. Because only that client should know the proper cookie. Every time a client locks a record, they should get a new cookie value that no one else knows.
I guess this is some kind of timestamp.
No, if you use a timestamp it's too easy for different clients to get the same cookie value, becuase they requested locks at nearly the same time (and System.currentTimeMillis() usually rounds to the nearest 10 milliseconds - a lot can happen in the computer during the same 10 ms interval.
I think most of us are generating random numbers for the cookies.
Do I need to implement this functionality?
I am planning to implement these methods as is, but not to use the cookie at all.

The Data class needs to have methods that behave as described. Your GUI may never really need all those methods, but the Data class still needs to have them; it's part of your requirements.
I think I dont need it, it is not possible in my application for others to unlock the record locked by someone else.
I agree; the cookies seem like a waste of time. However we're required to implement them anyway. Think of it this way - if another programmer comes along later and changes your client or network code without understanding it properly, and somehow breaks it, the cookies will make it easier to detect the problem. That's the only use I can think of for them. But even if they have no use, we're still required to implement them in the Data class.
 
Manoj Gundawar
Ranch Hand
Posts: 169
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Jim.
That was a clear, elaborated answer. I guess I will also use the similer long value (like random no)
So more code for nothing I will have to do it for getting the Sun's stamp on me
Thanks,
manoj
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Manoj
So more code for nothing I will have to do it for getting the Sun's stamp on me

Unfortunately this happens all too often even in the real world. I have lost track of the times I have had to implement a bad design because it had already been sold to upper management and my managers were not willing to go back and state that there was a better / easier solution.
It is quite possible that Sun are actually looking for the ability to do exactly what you are told, regardless of how you feel. Kathy Sierra and Bert Bates recomend adopting a "team player" attitude. So even if you disagree with Sun's coding standards, you still should use them. Even if you disagree with the methods of the interface you still have to use them. Then you will be more of a team player, and are more likely to get on well in your work.
Apropos: There was a Dilbert cartoon where Dilbert was given a choice of two evils: having a higly respected job with minimal wages, or a job with high wages but all his work would be burnt in front of him every night. His response: both options are better than the current job. I can relate to that.
Regards, Andrew
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew,
I totally agree with what you write about that cookie issue. It's a "must-be" requirement which could lead Jmannu to an automatic failure if he doesn't respect it. But your arguments are too general to be applied to a no "must-be" express requirement IMO. See our discussion about handling IOException, and it's just an example.
Here are two excerpts of my own assignement (URLyBird 1.2.1) which I (try to) never forget :
This document deliberately leaves some issues unspecified, and some problems unraised. Your ability to think through these issues, in the face of realistically imperfect specifications, and come to a tenable solution is something upon which you are being graded.

For any design choice concerning topics not specifically described in the requirements, marks are awarded for a clear and consistent approach, rather than for any particular solution.

Best,
Phil.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To be more precise, I 'd like to add this :
There are two kinds of stupid things in our instructions :
  • The "must-be" stupid things : Sun is fair enough to let us understand easily that it's a "must-be" thing : the word "must" is in the requirement.
  • Other stupid things, for which the instructions state expressly that you'd better to be smart against them if you claim for a high score.


  • Agreed ?
    Best,
    Phil.
     
    Andrew Monkhouse
    author and jackaroo
    Marshal Commander
    Pie
    Posts: 12014
    220
    C++ Firefox Browser IntelliJ IDE Java Mac Oracle
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Philippe
    Yes, I do agree.
    A perfect example of the "Other stupid things" is the "null terminated fields" which Sun expect people to realise are space filled fields.
    There are going to be issues where there are conflicting requirements, or where the specifications do not match the data, and in these cases people need to make intelligent decisions.
    There are also going to be times where there is more than one solution to a proble, and a design decision will have to be made - hopefully with intelligent forethought
    Unfortunately there are also issues that come up from time to time, where people are just going to have to accept that they have to do things Sun's way, even if they don't like it.
    Regards, Andrew
     
    Manoj Gundawar
    Ranch Hand
    Posts: 169
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Andrew,
    Hi Philippe ,
    Oops! So much of brain storming happened after my last post! All your comments are quite valid. I too face this situation sometimes. And special thanks to Andrew for his comments "Other stupid things" is the "null terminated fields" which Sun expect people to realise are space filled fields.
    Cause I had this query in mind and I was about to post this query on the board. But you helped to avoid one more thread in this (too many) thread full life of ranch.
    Thanks,
    Manoj
    [ August 06, 2003: Message edited by: Jmannu gundawar ]
    [ August 06, 2003: Message edited by: Jmannu gundawar ]
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic