• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

NX : throwing RecordNotFoundException?

 
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 697
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 697
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey Vish, thanks man!
 
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

"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?
reply
    Bookmark Topic Watch Topic
  • New Topic