In my doc of SCJD: Data file Format The format of data in the database file is as follows: Start of file 4 byte numeric, magic cookie value. Identifies this as a data file 4 byte numeric, total overall length in bytes of each record 2 byte numeric, number of fields in each record Schema description section. Repeated for each field in a record: 2 byte numeric, length in bytes of field name n bytes (defined by previous entry), field name 2 byte numeric, field length in bytes end of repeating block Data section. Repeat to end of file: 1 byte "deleted" flag. 0 implies valid record, 1 implies deleted record Record containing fields in order specified in schema section, no separators between fields, each field fixed length at maximum specified in schema information End of file All numeric values are stored in the header information use the formats of the DataInputStream and DataOutputStream classes. All text values, and all fields (which are text only), contain only 8 bit characters, null terminated if less than the maximum length for the field. The character encoding is 8 bit US ASCII. and the DBAccess like : // Modifies the fields of a record. The new value for field n // appears in data[n]. Throws SecurityException // if the record is locked with a cookie other than lockCookie. public void updateRecord(long recNo, String data, long lockCookie) throws RecordNotFoundException, SecurityException; // Deletes a record, making the record number and associated disk // storage available for reuse. // Throws SecurityException if the record is locked with a cookie // other than lockCookie. public void deleteRecord(long recNo, long lockCookie) throws RecordNotFoundException, SecurityException; .... the first question is : Does the lockCookie == magic cookie value which in the top of file? I means: when a client update a record , I write a cookie in top of file. and then other people cann't update the file even he want to update other cookie? the second question is : what can i generate a cookie for a client ? uses random? if use random, when the same client run again , which way can he generate a cookie again?
Does the lockCookie == magic cookie value which in the top of file? No, they are different. There's nothing really for you to do with the magic cookie, it seems. what can i generate a cookie for a client ? uses random? Sounds good. if use random, when the same client run again , which way can he generate a cookie again? The client needs to save the cookie value that is returned from lock(), and use that in any subsequent update(), delete(), or unlock(). [ June 03, 2003: Message edited by: Jim Yingst ]
Hi Gy, 1. The first 4 bytes are a file signature. It has no other meaning that to ensure yourself that the file you open is well a data file with the format you expect. You can simply ignore it, or - if you want to do a little more - check its value and throw such an InvalidFileException of your own if the value read is not the one you expect. 2. I have the same assignment as yours, and I have not yet decided for sure. But at first sight, I will use some class acting like a sequence generator in a db system, like this one :
Joined: Jun 02, 2003
what can i generate a cookie for a client ? uses random? Sounds good.
How do you make sure that two clients do not receive a same cookie ? Maybe I missed something there ?
Although I am not Jim, I'll try to give you a hint: what I do is create a random long nr.; I maintain a Map with record numbers and the corresponding cookie numbers; before returning a cookie to the client, I check if it is present in my Map... Hopefully this helps... TK
Joined: Jan 30, 2000
How do you make sure that two clients do not receive a same cookie ? I don't. If someone wants to use their cookie to try to unlock some other record that was locked by another client, well, there's a 1 in 2^64 chance that it will work. That's low enough for me. And consider - if someone is writing client code to try to unlock other clients' locked records, why not just use a cookie value of 0, or 1, or 124356789L, or just generate a random long of their own? You get the same 1 in 2^64 chance. Eliminating cookies that have already been used doesn't change this much, IMO. Thomas - just to clarify, in your Map the keys are record numbers, and the values are cookies, right? Or is it the other way around? I'm guessing the Map is primarily for storing the cookie so you can later check it when update(), delete(), or unlock() is called, right?
Hi Jim Yingst, I am using System.getCurrentTimeMillis() to generate cookie value. Moreover, I am locking the record in the server side only. For example,
If calling the lockRecord() from UI, we need to handle client crashes, and moreover, we need to run a thread to check and release locks if the locking time expires the specified amount of time. Till then record is locked. But in real world, like passenger booking system, even if we got displayed with the current availability, it may not be the exact figure, as other threads may decrement the available seats. Please provide your comments Jim. Thanks n Regards, Ganapathy
Joined: Jan 30, 2000
I am using System.getCurrentTimeMillis() to generate cookie value. OK. I prefer Random's nextLong() since it feels more "secure" than System.currentTimeMillis() (it has more possible results) - but realistically, security isn't a big concern for this assignment, and the cookies aren't really used for anything except maybe detecting programming errors with regard to thread safety. We can write the server code so that different clients can't possibly make concurrent updates - but the cookies offer an extra check to make sure we did it right. So using current time seems fine. I just like random numbers better. If calling the lockRecord() from UI, we need to handle client crashes, and moreover, we need to run a thread to check and release locks if the locking time expires the specified amount of time. Till then record is locked. But in real world, like passenger booking system, even if we got displayed with the current availability, it may not be the exact figure, as other threads may decrement the available seats. Agreed - for the assignment we have, a closed lock-read-check-update-unlock block like you show seems sufficient, and so the client never needs to know the cookie, or access lock() independently - it just calls bookRecord(), and checks whether it succeeded or not. Letting the client lock() the record without unlock()ing immediately after might be useful for future enhancements - like if the client wants to edit a lengthy record, and prevent others from tampering with it while it's being worked on. But you're right, we don't seem to need it now, and the need (or at least, strong preference) to time out locks would be an extra complication we'd prefer to avoid. So I agree with your statements.
Joined: Mar 26, 2003
Hi Jim Yingst, Thankyou very much for providing your comments. I also looked into Random's nextLong(), which is good. I tested my code for System.currentTimeMillis(), it is working fine. But I am not happy with that, as OS will return with a precision of 10 milli seconds (I tested this on Win 2000 professional). So this does not generate unique numbers, if say 5 clients lock records with in 10 milli seconds precision, all threads may get the same lock cookie. This I found while testing. So I am looking at Random's nextLong() only. Regards, Ganapathy.
Joined: Feb 13, 2002
Jim, Correct: the recordnumber is the key, the cookie the value. In the update / delete, I get the cookie from the Map (using the recordNo key), and check if it equals the supplied cookie... You're correct when you say that the chance is small that you'll get two the same random numbers, but checking was quite easy to implement... and better safe than sorry Greetings, TK