Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S - Implication of SecurityException in DB interface methods

 
Alan Mac
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 11944
212
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Alan Mac
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic