It's not a secret anymore!*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: URLYBird - what is the recNo in DBAccess interface? 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 "NX: URLYBird - what is the recNo in DBAccess interface?" Watch "NX: URLYBird - what is the recNo in DBAccess interface?" New topic
Author

NX: URLYBird - what is the recNo in DBAccess interface?

Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hello all,
I think its a pretty dumb question, but I could'nt figure it out on how to do. Please suggest me, thanks.
In the DBAccess interface that is provided by Sun, many functions are taking recNo as an argument. Some of the code in the given interface looks like
public interface DBAccess
{
// Reads a record from the file. Returns an array where each
// element is a record value.
public String [] readRecord(long recNo)
throws RecordNotFoundException;
// 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;
// Creates a new record in the database (possibly reusing a
// deleted entry). Inserts the given data, and returns the record
// number of the new record.
public long createRecord(String [] data)
throws DuplicateKeyException;
// Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.
public long lockRecord(long recNo)
throws RecordNotFoundException;
.............
.............
}
As far as I understood, there is no field in the db.db that correlates to the recNo in the above interface. I think this recNo acts like an index to the records in the db.db and we need to store them in an ArrayList(I'm not sure whether its ok? or use others). But I could not figure it out on how to relate the records in the db.db file with the recNo in the given interface.
Can anyone give some suggestion on how to relate the records in database with the recNo? And if we need to generate the recNo's and then relate them to records in db.db file, can I generate them like the cookie value(Please see my ideas on cookie generation)?
And I have another question. This one is regarding the cookie value. I'm thinking of a couple of ideas to generate the unique cookie value. One is using the Math.random() method. Other one is using the Date.getTime() method. Is this is a valid and reasonable approach. Or can I just use numbers 1,2,3... as lockCookie value.
Please suggest me on how to deal with the above problems. Really appreciate your help. Thanks.
Raj Shekhar
Greenhorn

Joined: Jan 26, 2004
Posts: 25
Satish,
There is no record no. in database and I many people(including me)assumed it as an indication of the Physical location of the data. for eg. if the header information is 20 bytes long and each record is 50 bytes long then record 1 will start at position 20 and record 2 will start at 70 etc.
There are other approaches to handling this including creating a initial cache collection of records. Hope this helps.
If you plan on using the Random() for generation of cookie value, be careful how you do it as it is not gaunranteed that you will get unique values.
If you use a long values and increment it, at some point it will exceed the ceiling of long and will give an overflow error. I am using this approach and I am planning to justify this by documentation and also by providing an option for resetting the long value.
I remember reading a thread here where people discussed the merits of using the system time as the cookie value(you should be able to find the thread by searching). If you have a fast computer, the algorithm could produce two cookies of same value. There was a workaround to it where you force the algorithm to wait for a millisecond so that the next number is unique.
hope this helps.
Raj
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi Raj,
First of all, thanks for the detailed explanation. I think, I got an idea regarding the cookie value. As you said, I already did go through the thread that discussed about the system time that returns milli seconds as cookie. I will look into it again.
Coming to the recNo, as you said, if we take the recNo's as physical location, say by your explanation for eg. if the header information is 20 bytes long and each record is 50 bytes long then record 1 will start at position 20 and record 2 will start at 70 etc, then do we need to store the record numbers as 20,70,120,170,...? So, in the method while calling readRecord(long recNo), we can send the recNo as 20, right? And as you said this is one approach only. So, we need to think on these grounds(i.e. the physical start point of record in the data file) and should come up with similar ideas. Ok, I think I got it now.
Any other ideas to discuss are greatly welcomed. Appreciate all. Thanks.
Raj, thanks once again.
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Satish,
Originally posted by Satish Avadhanam:
Coming to the recNo, as you said, if we take the recNo's as physical location, say by your explanation for eg. if the header information is 20 bytes long and each record is 50 bytes long then record 1 will start at position 20 and record 2 will start at 70 etc, then do we need to store the record numbers as 20,70,120,170,...?

Or, you can use record numbers like 0, 1, 2, 3, 4,...
In this case, the record number refers to the physical order of the records in the database file. So recNo=0 is the first record in the database file, recNo=2 is the second record in the database file, etc.
When you want to access a particular record in the database file then you'll want to determine the proper location. The location of a record can be calculated given the location where the record data starts (the data offset from the start of the data file which is based on the size in bytes of the header and schema sections), the record number, and the size of a record in bytes. It's a pretty straightforward formula so I'll leave it to you as an exercise.


Regards, George
SCJP, SCJD, SCWCD, SCBCD
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi George,
First of all Congrats for your perfect score (400/400).
Thanks for the response. I got the idea of how to use the recNo now. I will go with the physical location of the record in the database file as the recNo.
Thanks alot. I really hope you stick around this forum and help those like me who are dying to get a SCJD by their name.( or atleast stick around till I pass )
Originally posted by George Marinkovich:

Or, you can use record numbers like 0, 1, 2, 3, 4,...
In this case, the record number refers to the physical order of the records in the database file. So recNo=0 is the first record in the database file, recNo=2 is the second record in the database file, etc.

And George, from above you mean that recNo=0 is the first record and recNo=1 is the second record, not recNo=2, right?
[ February 17, 2004: Message edited by: Satish Avadhanam ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX: URLYBird - what is the recNo in DBAccess interface?