aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S - Implication of SecurityException in DB interface methods 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 "B&S - Implication of SecurityException in DB interface methods" Watch "B&S - Implication of SecurityException in DB interface methods" New topic
Author

B&S - Implication of SecurityException in DB interface methods

Alan Mac
Greenhorn

Joined: Aug 03, 2005
Posts: 9
Hi all,

I have the Bodgitt & Scarper v2.1.1 assignment.

So far, I have written my app using a DBAdapter class to wrap the business logic (including the lock/unlock calls) before calling the underlying methods in the Data class. For example, a book(...) call from client goes to a book(...) method in DBAdapter which calls the lock/update/unlock methods in the underlying Data class.

However, I've come across a problem. In my DB interface, the update(...) and delete(...) methods are defined as throwing SecurityException. So my data access implementation class, Data, must implement these methods, each throwing a SecurityException if the record is locked with a cookie other than lockCookie. This implies that locking/unlocking should be carried out in the Data class, rather than abstracted out into a business layer?

Also, the fact that update/delete methods in Data take a lock cookie as a parameter suggest that locking/unlocking should be done in the Data class.

Am I missing something here...

Thanks
A.
[ August 19, 2005: Message edited by: Alan Mac ]
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11423
    
  85

Hi Alan,

The way I read the instructions, in particular the information provided with the interface, is that your Data class must be capable of standing alone and providing all the functionality specified in the interface.

That is: it should almost be possible for somebody to take a Data class written by somebody else and use it as a replacement in your solution. Or take your Data class and use it as the building block for some other application.

But if you delegate functionality to some other class(es) you will not be able to meet this requirement: another programmer will not be able to use your Data class unless they also use your 'x' class. In which case, why have the methods in the Data class?

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Alan Mac
Greenhorn

Joined: Aug 03, 2005
Posts: 9
Hi Andrew,

Yes, that's pretty much how I saw it too. I assumed Sun set these specifications so that they could run a test harness against the Data class to verify that the methods worked correctly. However, I've seen a lot of posts where people talk about abstracting the business logic (and locking/unlocking) into a DBAdapter class where they wrap the lock/unlock calls before calling methods in the underlying Data class. I guess this is a good idea but not appropriate in my case!

Again, thanks for your opinion on this one Andrew.

A.
Jesse Xie Y.S.
Greenhorn

Joined: Feb 09, 2004
Posts: 20
I just thinking about the SecurityException again. In this forum, every body all thought that the securityException should be a checked exception. But I don't think so.

User the CSR's don't know there are some cookie exist in URLyBird program, maybe they know how to correct the FileNotFoundException and RecordNotFoundException, but they don't understand the cookie and don't know how to correct the SecurityException too.

So, I think that SecurityException is not a checked exception. It's a runtime exception. It's occured only by programer.


MOON -- SCJP1.2
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: B&S - Implication of SecurityException in DB interface methods