aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Status & Cookie 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 "Status & Cookie" Watch "Status & Cookie" New topic
Author

Status & Cookie

Ray Dawson
Ranch Hand

Joined: Sep 16, 2011
Posts: 75
#1: I'm getting the order no. from the db file to the jtable, so my table's last column looks like say 12345678 etc. Shall I keep it that way or customize the cells with "Available / Not Available" labels ??

#2: "Cookie must be the cookie returned when the record was locked" - What is a cookie anyway ? For the locking part am asking the user for a password, which along with the customer id must both match in order to release or lock any record. But it says the cookie has to be a long number, so how should i approach this ?
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5407
    
  13

1/ the last column in my table is also the customer id

2/ the lockCookie is a value you generate in your Data class (or locking manager class). So you store this value in the Data class (or locking manager class) together with the record number. So you'll be able to identify the client (and know if this client can update a given record), so no password has to be given in order to lock/update/delete/unlock a record.


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Ray Dawson
Ranch Hand

Joined: Sep 16, 2011
Posts: 75
Roel De Nijs wrote:1/ the last column in my table is also the customer id

2/ the lockCookie is a value you generate in your Data class (or locking manager class). So you store this value in the Data class (or locking manager class) together with the record number. So you'll be able to identify the client (and know if this client can update a given record), so no password has to be given in order to lock/update/delete/unlock a record.


#1: Yep the last column is the Customer ID for me as well But what about those records which are open & don't have an id ?

#2: Again I did exactly the same thing, but how does the user know what is the lockCookie value ? The thing which I did was used an algorithm to convert the user given password as the long lockCookie, so when user enters the pass that value is converted to cookie value.

BTW, what is the essay exam all about ? How do I prepare for that ?
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5407
    
  13

1/ these are bookable.

2/ it's something that happens behind the scene, the end user does not have (or need) any knowledge about the lockCookie.

Ray Dawson wrote:BTW, what is the essay exam all about ? How do I prepare for that ?

Answers are easy to find in ScjdFaq and the search engine of the forum
Ray Dawson
Ranch Hand

Joined: Sep 16, 2011
Posts: 75
#1: Bookable for sure but does the last column should look like this
12345678

45678912
69874103

56987023

11112556

Or should they look like

Not Available
Available
Not Available
Not Available
Available
Not Available
Available
Not Available
Available

I was just asking about the design as to which one would look good ?


#2: So its ok to ask the user for pass while I do the background stuff of the lockcookie etc right ?
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5407
    
  13

1/ that's your own choice. Opting for available/not available does not have a lot of added value in my opinion

2/ you don't have to ask a user for a password at all!
Ray Dawson
Ranch Hand

Joined: Sep 16, 2011
Posts: 75
Roel De Nijs wrote:1/ that's your own choice. Opting for available/not available does not have a lot of added value in my opinion

2/ you don't have to ask a user for a password at all!


#1: Alright, Thanks

#2: I already implemented the password part, so is it ok to keep it ??
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5407
    
  13

You definitely should document that decision, because it's extra work for each CSR with each booking. It will slow down the booking process and I don't see any added value in your approach.
Ray Dawson
Ranch Hand

Joined: Sep 16, 2011
Posts: 75
Roel De Nijs wrote:You definitely should document that decision, because it's extra work for each CSR with each booking. It will slow down the booking process and I don't see any added value in your approach.


If the customer is not asked for any pass then hw does the unlocking process works ?
Is it that the customers only needs to remember their ids & not anything else ?
Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

If the password that the customer enters is used as the lock cookie, then what is to stop two customers entering the same password?


SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Ray Dawson
Ranch Hand

Joined: Sep 16, 2011
Posts: 75
Sean Keane wrote:If the password that the customer enters is used as the lock cookie, then what is to stop two customers entering the same password?


I know that's why I want the user to enter their customer id & second their password, which I convert in to long & add another random long to build the main long lockCookie.

Then use both ID & cookie to lock unlock the data.


I have a question for you i.e.

If the user doesn't know anything other than customer id then how does he unlocks the data, provided the fact that the lockcookie is some random num stored somewhere ?
So that means anyone knowing the customer id can manipulate records ???
Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

You have just explained how your use of the password and customer number is completey redundant in generating your lock cookie value. Why? Because you generate a random number.

Neither the password or customer number guarantee uniqueness. That is why you also use a random number.

Hopefully this should make it clear that your password funtionality is pointless and all you need for the lock cookie is one single value that is guaranteed to be unique across the entire application regardless of how many users there are.

Ask yourself two questions:

(1) Where in my code can I generate a value so I can be guaranteed that only the method that is generating the unique value is only being executed by one thread? Hint - server side.
(2) What long can I use for my unique value? Hint - search the forum.

Put simply - you are on the wrong track and you need to rethink your solution. Hope this helps.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5407
    
  13

Sean Keane wrote:Put simply - you are on the wrong track and you need to rethink your solution. Hope this helps.

I agree with Sean (as so many times ) and I illustrate that with a fact: I'm an active visitor of this forum since January 2009 (so that's almost 3 years) and you are the 1st person introducing entering a password to lock/unlock records.

It seems to me you have maybe a misunderstanding about the booking process. In my GUI I just have a book-button (no lock/unlock button). When the user hits the button, a dialog opens where the user can enter the customer id (who wants to book the room) and then he confirms the dialog and the booking is executed. And to execute the booking the following code (in its most simplest form of course, the actual code has some exception handling etc.) is executed:

So the cookie is just something you have to generate, store and verify when needed. But the user will never have any idea a record is locked, updated and unlocked. He doesn't need to know that, because he's just interested in booking the record

Hope it helps!
Ray Dawson
Ranch Hand

Joined: Sep 16, 2011
Posts: 75
What does the server check the LockCookie value against ?
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5407
    
  13

Ray Dawson wrote:What does the server check the LockCookie value against ?

You clearly don't understand the locking mechanism you have to implement and what's the purpose of this mechanism. Maybe you should read the part in ScjdFaq about the lock method to have a better understanding (and you'll be able to answer this question yourself)
Ray Dawson
Ranch Hand

Joined: Sep 16, 2011
Posts: 75
Roel De Nijs wrote:
Ray Dawson wrote:What does the server check the LockCookie value against ?

You clearly don't understand the locking mechanism you have to implement and what's the purpose of this mechanism. Maybe you should read the part in ScjdFaq about the lock method to have a better understanding (and you'll be able to answer this question yourself)


I didn't read the FAQ, but here's what I did.

When new user creates a record a cookie file saved on his machine & a copy of the lockcookie is also saved on the server.
When the same record is accessed the server matches the cookie value on client's machine with its own stored value for that record, if it matches the record can be updated/ manipulated
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5407
    
  13

Ray Dawson wrote:When new user creates a record a cookie file saved on his machine & a copy of the lockcookie is also saved on the server.
When the same record is accessed the server matches the cookie value on client's machine with its own stored value for that record, if it matches the record can be updated/ manipulated

Nobody speaks about a cookie file (like in a web application and like your browser uses), but just about a cookie value. So again you did way too much and for someone who is short on time that's valuable time wasted. But if you just ignore advice that's your own fault.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Status & Cookie