Hi, This is my first posting on this forum, and I'm asking because I haven't been able to find any other threads discussing this topic.
I've created a Data class which implements the interface sent by Sun. The Data class has a LockManager dealing with locking, and a FileDataSource which reads and writes a RandomAccessFile.
I've decided to create a Socket based network solution, and each time the SocketServer class gets a client socket request, it creates a new Data instance for that request. In this way each client has a unique Data instance on the server side.
In pseudocode my lock method in the Data class looks like this:
My question is if it's "legal" to use the Data class hashCode() as lockCookie when trying to lock a record? If it can cause any problems, please let me know.
Johnny [ February 20, 2008: Message edited by: Johnny Peyton ]
Even I had used System.currentTimeMillis() to generate the cookie.The requirement of the cookie is that it should be difficult to guess.So any method that satisfies this can be used
SCJP 5, SCWCD 1.4, SCJD 5
Joined: Feb 20, 2008
Thanks for your answers.
It's not the value of the cookie I'm concerned about. It's more that if I use the hashCode of the Data instance, the cookie returned to the client is superfluous.
1) A client wants to update a record
2) Locks the record and retrieves a cookie to use when updating. The server stores the recNo that was locked with the cookie, that is the hashCode of the client (the Data instance)
3) When the client calls the update method on the server is passes the cookie value it got from the lock method. My concern is that the server really don't need to check the cookie value sent from the client. The client is identified through it's hashCode, and the server just needs to check the hashCode against the one stored with the recNo. Thus the cookie is superfluous.
I feel there's something wrong about this, but I can't put my finger on it. Can anyone else please tell me if I'm going to fail delivering a design like this, or will it be accepted?