This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX : throwing RecordNotFoundException? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX : throwing RecordNotFoundException?" Watch "NX : throwing RecordNotFoundException?" New topic
Author

NX : throwing RecordNotFoundException?

Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi all,
Actually posted this doubt in another locking but thought starting a new thread will make some sense. Am gonna delete the post there. Please comment on this here...thanks.
I got a doubt regarding the throwing of RecordNotFoundException(RNFE). Am quoting the Sun's statement for convenience.

Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file.

The following methods throw RNFE: read, update, delete & lock. Here is what am doing right now. I populate two static ArrayList's existingRecords and deletedRecords before any client access the dbfile. Later on, I use those two arraylist to find out whether the record exists or not or whether the record is already deleted or not like that. If any new record is created using the create method I add that record to the existingRecords arraylist. So what I exactly do at the time of checking for the RNFE in the above methods is to check whether the recNo is present in the existingRecords. If not it will throw RNFE.
Does this approach fulfill the RNFE requirement? Thanks for your comments.
And here is another quote from the requirements:

but because the data must continue to be manipulated for reports using another custom-written application,

So what is concerning me is do we have to read all the records present in the db file everytime we access it? I mean there is always a chance that other applications might be adding or deleting the existing records right? What if our application is used only to pull the db file and show and other applications are used to add and delete records? Then we have to read all the records in the db file everytime we access it, say we want to read, delete and other operations.
Am I correct? Or totally wrong? Guys...please, any comments on this?
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
HI Satish,
Originally posted by Satish Avadhanam:
So what is concerning me is do we have to read all the records present in the db file everytime we access it? I mean there is always a chance that other applications might be adding or deleting the existing records right? What if our application is used only to pull the db file and show and other applications are used to add and delete records? Then we have to read all the records in the db file everytime we access it, say we want to read, delete and other operations.
Am I correct? Or totally wrong? Guys...please, any comments on this?

I don't think there is a chance that other applications might be adding or deleting the existing records while our application is running. I think this possibility is precluded by the following from the assignment instructions:

Locking
Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above. You may assume that at any moment, at most one program is accessing the database file; therefore your locking system only needs to be concerned with multiple concurrent clients of your server. Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, consuming no CPU cycles until the desired resource becomes available.

At any one time there is only one application accessing the database file. In other words, we do not have to worry about the legacy application accessing the database file while our application is running. Similarly, we do not have to worry about two instances of our application running in standanlone mode on the same machine accessing the same database file.
In my opinion Sun is explicitly offering us a simplifying assumption and we are foolish not to take them up on the offer.


Regards, George
SCJP, SCJD, SCWCD, SCBCD
Vishwa Kumba
Ranch Hand

Joined: Aug 27, 2003
Posts: 1064
In the realistic world for example: Oracle.....Concurrent access to the database is provided to different clients, but locking and writing physically to the data files is managed by Oracle itself. There are no multiple external programs that lock or write to the database(oracle data files) directly at the same time. Everything is managed by Oracle.Even though the OS may support it, this might corrupt the data files if proper synchronization is not maintained.
Anyway, George has clarified this.
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hi George, thanks for the response.
Originally posted by George Marinkovich:
HI Satish,
At any one time there is only one application accessing the database file. In other words, we do not have to worry about the legacy application accessing the database file while our application is running. Similarly, we do not have to worry about two instances of our application running in standanlone mode on the same machine accessing the same database file.

So, you think reading all db file records at the start of the application (and adding any created records to that) should work and we don't have to do reading from db file each and everytime. OK, thanks.

In my opinion Sun is explicitly offering us a simplifying assumption and we are foolish not to take them up on the offer.
Its just that we are putting so much effort(ofcourse money too) to pass the test right. So don't want to let it go for small statements and if anyone here(You, Phil, Javini) assures that its ok, it will be a relief.

Thanks.
Satish Avadhanam
Ranch Hand

Joined: Aug 12, 2003
Posts: 697
Hey Vish, thanks man!
Javini Javono
Ranch Hand

Joined: Dec 03, 2003
Posts: 286
Hi,

The following methods throw RNFE: read, update, delete & lock. Here is what am
doing right now. I populate two static ArrayList's existingRecords and
deletedRecords before any client access the dbfile. Later on, I use those two
arraylist to find out whether the record exists or not or whether the record is
already deleted or not like that. If any new record is created using the create
method I add that record to the existingRecords arraylist. So what I exactly do
at the time of checking for the RNFE in the above methods is to check whether
the recNo is present in the existingRecords. If not it will throw RNFE.
Does this approach fulfill the RNFE requirement? Thanks for your comments.

Those with more experience may have better advice than what I offer, but I'll
take a stab at your question.
In my assignment, also unlock() and isLocked() throw RecordNotFoundException;
I would suggest that even if your unlock() and isLocked() don't, that it would
be consistent if they did (which is easy enough to do if RecordNotFoundException
is a runtime exception).
Now on to your specific question. Before answering, I should add that for my
assignment I have added the following additional and extra constraint: my
database can be arbitrarily large; thus, I try to avoid solutions which involve
holding potentially large collections of data in memory.
To determine that a record physically exists within the database, this can be
computed by knowing the file's current physical length; and, that is what I
do.
Concerning how to delete records (which, interestingly enough, is somewhat
related to creating records): this I have been thinking about just recently.
Again, my additional constraint is that I do not want to hold potentially large
collections of data in memory. Here is my current plan of action:
DELETION
--------
When the application starts up, it scans the database to create a collection
list of deleted records, call this deletedRecords. This collection,
deletedRecords, will have an arbitrary maximum allowed size so that the JVM
does not run out of memory. Whenever a record is deleted, that record number
is added to this collection. However, if adding a record to deletedRecords will
increase its size beyond its MAXIMUM_ALLOWABLE_SIZE, no further records are
added to this collection.

CREATION
--------
My creation facilities allow two types of creation: (1) at the end of the file
or (2) to over-write an inactive (deleted) record in place.
When a record is about to be created, if deletedRecords contains at least one
item, this record number is used to create a new record where the previously
deleted record was (i.e., creation of a new record is done in place).
However, if deletedRecords.size() == 0, then the new record is written to the
end of the file.
I will have an additional facility wherein the client can request that a
record be created in place at a specific record number in the file, though
there is no guarantee that this will occur (I added this feature so that
using JUnit is easier).
Conclusion
----------
The above topics I am currently working on as I write this. My current,
operational program only creates new records at the end of the file, but, I have
decided to allow it to create new records in place. The above design attempts
to find a reasonably simple, but efficient way of doing this without violating
my additional constraint that no collection used in the program should become
overly large.
Since I just came up with these ideas last night, there may be subsequent
changes to my algorithms once I get to implementing them this morning.
Thanks,
Javini Javono
Vishwa Kumba
Ranch Hand

Joined: Aug 27, 2003
Posts: 1064
"Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file."

The following methods throw RNFE: read, update, delete & lock. Here is what am doing right now. I populate two static ArrayList's existingRecords and deletedRecords before any client access the dbfile.
Later on, I use those two arraylist to find out whether the record exists or not or whether the record is already deleted or not like that. If any new record is created using the create method I add that record
to the existingRecords arraylist. So what I exactly do at the time of checking for the RNFE in the above methods is to check whether the recNo is present in the existingRecords. If not it will throw RNFE. Does this approach fulfill the RNFE requirement?

Satish,
For your cache, maybe you can get away with just having one ArrayList, with record status or even better a HashMap(record, status).The record numbers are unique. Aren't they?...

Usually, with any cache-mechanism, we look into the synchronization issues. So I wonder if there are any cases, in which your cache can go into a "stale condition" or become inconsistent with the database.

I could think of the foll. 2 cases :

1. Can the application crash while updating the db file or the cache?
- Quite possible, but this can be ruled out as as our cache would
be refreshed when we restart the application. Moreover this is supposed to be a simple application, so no complex recovery mechanisms.

2. Can there be other applications accessing db file at the same time and
changing the status of the records?
- Can we ignore this? From George's reminder, it looks like there
could be other clients of your same server accessing the database at the same time and changing the records, so this could affect your record statuses. So this cache of yours needs to be shared among the clients, which happens to be in your case.(static).
But is it thread-safe?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX : throwing RecordNotFoundException?
 
Similar Threads
RecordNotFoundException and unlock
RecordNotFoundException in find(...) method
nx: All of URLy Bird 1.1.3 read/write lock(2)
nx:All of URLy Bird 1.1.3 about delete and update method
locking assumptions