File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes RecordNotFoundException and unlock 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 "RecordNotFoundException and unlock" Watch "RecordNotFoundException and unlock" New topic
Author

RecordNotFoundException and unlock

Jörgen Lundberg
Greenhorn

Joined: Dec 08, 2005
Posts: 10
I'm doing the Bodgitt & Scarper assignment and I have a question about the RecordNotFoundException (RNFE). This is a quote from the description of the DB interface:
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 unlock method throws RNFE but I don't see how a situation that causes the RNRE can happen.

If you get a lock with the lock method the record exists, otherwise you'll get a RNFE. If you unlock a record you don't have a lock cookie for you'll get a SecurityException.

Can I just declare the RNFE for the unlock method but never throw it...?
Am I missing something obvious...?
Chris Hurst
Ranch Hand

Joined: Oct 26, 2003
Posts: 418
    
    2

My unlock throws SecurityException (B&S) ??? not RNFE


"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Jörgen Lundberg
Greenhorn

Joined: Dec 08, 2005
Posts: 10
This is a quote from the DB interface in the html-file that defines the developer assignment.
(Sun Certified Developer for the Java 2 Platform: Application Submission (Version 2.1.1))

Timothy Frey
Ranch Hand

Joined: Jul 22, 2006
Posts: 56
I have the same requirement in my project. My interpretation was to throw a RecordNotFoundException when someone tries to unlock something that hasn't been locked before. Some people don't have this requirement, so in their programs trying to unlock a record that hasn't been locked doesn't do anything. Not sure if my interpretation is correct but seems good to me!
Chris Hurst
Ranch Hand

Joined: Oct 26, 2003
Posts: 418
    
    2

I'm on 2.2.2

// Releases the lock on a record. Cookie must be the cookie
// returned when the record was locked; otherwise throws SecurityException.
public void unlock(long recNo, long cookie)
throws SecurityException;

Looks like they changed it at some point :-)
Jörgen Lundberg
Greenhorn

Joined: Dec 08, 2005
Posts: 10
My interpretation was to throw a RecordNotFoundException when someone tries to unlock something that hasn't been locked before


My interpretation of that scenario would be this:
If the record hasn't been locked before you wouldn't have a valid lock cookie and hence would throw SecurityException.
Timothy Frey
Ranch Hand

Joined: Jul 22, 2006
Posts: 56
Throwing a SecurityException makes sense also; I guess you just have to state your reasoning in the choices.txt file. In my program, I make the distinction between having an invalid lock cookie and not being able to compare the cookie because it doesn't exist in the first place.

Another approach would be to couple your record keeping module with your locking module. Most people decided that this is a pretty bad idea. However, it's not unworkable and you would be able to tell if the record exists before attempting to lock it.
Lucy Hummel
Ranch Hand

Joined: Apr 07, 2005
Posts: 232
Hi,

After I re-read this discussions. I checked my code. What I think is to throw a RecordNotFoundException in case the record is not looked or does not exists at all. Right now, I always throw java.lang.SecurityException.

But I wonder if java.lang.SecurityException is quite okay. I just faced the question if I can re-use the SecurityException out of the java.lang package.

What are your opinions on re-using java.lang.SecurityException?

Br, Lucy


----------------------------------<br />| SCJP, SCWCD, SCBCD, SCEA, SCJD |<br />----------------------------------
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 918

Hi Guys

Hummel, take care in which condition you throw the RnF exception, I think that the specification are pretty clear :

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


So I think is like this :
SecurityException occurs when an user tries to unlock a record without to lock(or own) it before (or more precisely a record can be released only by the same user which lock it).
the RecordNotFoundException occurs when the record is deleted (or does not exist).

Over and out.

Regards M
[ March 22, 2007: Message edited by: Mihai Radulescu ]

SCJP, SCJD, SCWCD, OCPJBCD
Jörgen Lundberg
Greenhorn

Joined: Dec 08, 2005
Posts: 10
the RecordNotFoundException occurs when the record is deleted (or does not exist).


The question is how can this happen? For the unlock method that is.
If the record is deleted or does not exist, how did you get the lock cookie?

About the SecurityException:
From the Java API:
Thrown by the security manager to indicate a security violation.

We don't have a security manager, so in that case the SecurityExeption is one of the unimplemented exceptions that are supposed to be implemented in the suncertify.db package, or?

You guys and girls who have passed the test, did you use java.lang.SecurityException or suncertify.db.SecurityException?
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 918

Hi J�rgen

Well, this depends, but a most common scenario is the delete record.
It is like this : under normal circumstances the look(and release) method can lock(or release) only existent (non deleted) records and the normal workflow for the Data class is lock, operate, release. Ok and now let's put all together and let try to delete a record : lock, delete, release. In this case you'll get always a RecordNotFoundException on release. More if release method can release only existent records you can not release the deleted records - and this can bring a lot of problems.
A solution for this will be to release the record after the delete and in this way to avoid to work with deleted(invalid) records. So in this case the scenario look like : lock, delete(ad release). If the user try to use a release after delete then he gets a RecordNotFoundException.
This solution simplify the user perception over the Database - the user only see the available records, he can lock - operate - and release them. If he decide to delete them well, he just locks - deletes them and they are gone.
Also the even the method release it self which throws a RFNException says that if the record is not existing then throw an Exception.
Wooow, that was a long post. It must be something in the cafe .

Regards M
[ March 22, 2007: Message edited by: Mihai Radulescu ]
Jörgen Lundberg
Greenhorn

Joined: Dec 08, 2005
Posts: 10
The clients of my server will never invoke the db-methods directly.
The clients will call business methods like list and book.

My thoughts on the unlock method is that if you have the unlock cookie fine, that record is now marked unlocked whether it exists or not.
Then there is no problem with the lock - delete - unlock sequence.

Therefore my unlock method will declare that it can throw RecordNotFoundException just to implement the DB interface, but it will never actually throw it.
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 918

Hi J�rgen

I agree with you, I also hide the DAO method from the client and provide only friendly methods. But you must also keep an eye on your solution the extensibility, if you provide a server which will serve only clients with a defined logic you'll reduce your system flexibility, I base my assumption on our affirmation :

The clients of my server will never invoke the db-methods directly.


The DAO must be able to server different clients (with different logic). I also think that the client(s) must follow the DOA rules, not backwards (the DAO must follow the client rules).

More, I also think that sun has already some test for the data class, and this test follows the original documentation so it is predictable that the check method will be proved over its contract. This test can bring you a automatic failure.

What you think about this ?

Regards M
Lucy Hummel
Ranch Hand

Joined: Apr 07, 2005
Posts: 232
Ho Mihai & J�rgen,

I totally agree with Mihai in his statement below:
Originally posted by Mihai Radulescu:

More, I also think that sun has already some test for the data class, and this test follows the original documentation so it is predictable that the check method will be proved over its contract. This test can bring you a automatic failure.


I think that it is pretty likely that Sun has such Junit to test against the DB interface that Sun has given to each of us.

Br, Lucy
Jörgen Lundberg
Greenhorn

Joined: Dec 08, 2005
Posts: 10
You are probably right about the automated tests...

I guess I have to follow the rules even though I think they are strange.
The perfectly normal lock - delete - unlock should, in my opinion, not throw an Exception. Exceptions are for unexpected error situations...

The lock and unlock methods are designed so that only one client at the time can operate on a specific record and if that client decides to delete the record that's not an exceptional scenario. If the unlock method is called on a deleted record this must be because the client with the lock cookie has deleted it. It cannot be because someone else has deleted it.
If the RecordNotFoundException is supposed to be thrown on a valid lock-delete-unlock sequence all the clients will have to catch and ignore that RNFE every time they delete a record and that is not a pretty design.

Even if Sun has the automated tests I cannot see how they could expect to get a RecordNotFoundException other than after deleting it while having the correct lock cookie.

But I guess I have to implement it that way, under protest...
Michael Creech
Greenhorn

Joined: Jan 22, 2006
Posts: 19
For my B&S assignment, The description for delete() is:



I interpret this to mean that delete() will implicitly unlock the deleted record. If this is not true, then the record can't be reused until some future unlock() operation is performed. With this interpretation, we have:
lock() --> update() --> unlock() -- ok
lock() --> delete() -- ok
lock() --> delete() --> unlock() --> throws either RecordNotFoundException or SecurityException depending on state of record (see below).

Unlock() Cases:
1) unlock(given recNo that doesn't exist or is deleted) - RecordNotFoundException
2) unlock(given wrong cookie or not locked) - SecurityException
3) unlock(correct cookie and locked) - perform unlock
----------------
SCJP1.4, SCJP1.5
Ken Boyd
Ranch Hand

Joined: Dec 10, 2003
Posts: 329
// 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 int create(String[] data) throws DuplicateKeyException;


Now in this case you have to the following

lock()=> delete()[set record flag to 1]=> unlock() it will not throw any exception because deleted record might be used again for creating new record at same location.

if user try to add new record where flag is 1 just set the flag back to 0 as if you have added new record at same location otherwise add new record at end of file.


SCJP, SCWCD, SCBCD, SCJD, BB Java2 and JSP1.1
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: RecordNotFoundException and unlock