Generating lockCookie

[Johnny Peyton]

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:

public long lock(int recNo) throws EXCEPTION {
    LOCKING_SUCCEEDED = lockManager.lockRecord(recNo, this);
    if LOCKING_SUCCEEDED {
        [B]return (long)this.hashCode();[/B]
    } else {
        throw EXCEPTION
    }
}

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 ]

[Herman Schelti]

hi Johnny,

The only thing I can think of that hashCode returns an int, and you have to return a long. The cookie will still be hard to guess for hackers, so I don't see a problem.

I wouldn't worry about it too much: I used System.currentTimeMillis() to generate a long.

Herman

[Herman Schelti]

hi Johnny,

on second thoughts:

your cookie mechanisme depends op

 it creates a new Data instance

If the famous 'junior programmer' changes that, he will probably forget to change the cookie-generator in your code.

Herman

[rohan tiwari]

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

[Johnny Peyton]

Hi,

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?

Johnny