Is checking for SecurityException in updateRecord method necessary?

[sunny hsiao]

Hello Ranchers,

I am doing the URLyBird project. and I have a question on the SecurityException that is thrown by the updateRecord method.


The JavaDoc for updateRecord(long recNo, String[] data, long lockCookie) below suggests that the updateRecord() method should do a check on the LockManager�s reservations (a hashmap object that stores the record number as the key and lockCookie as the value) against the parameters provided to the updateRecord() prior to committing the changes to the database.

// Modifies the fields of a record. The new value for field n
// appears in data[n]. Throws SecurityException
// if the record is locked with a cookie other than lockCookie.
public void updateRecord(long recNo, String[] data, long lockCookie)
throws RecordNotFoundException, SecurityException;

But investigating the business logic of how a record is locked, updated, and unlocked or the private property of the reservations, it seems it is not very likely that the SecurityException will be thrown at all.

If this is the case, should we still implement that checking against the LockManager�s reservations? (the hashmap object) For me, I implemented a method called checkForSameLockingOwner(long recNo, long suppliedCookie) in LockManager class and is called from the Data�s updateRecord method.

The SecurityException is thrown if checkForSameLockingOwner methods returns a false result.


Thanks.
[ April 30, 2008: Message edited by: sunny hsiao ]

[mohamed sulibi]

hiz;

think about another TestClass class that sun will run against you implementation that contains all cases that may fail you in assignment.

what you think ?

regards.
Mohamed Darim.

[sunny hsiao]

In my humble opinion, I don�t think it is possible for another TestClass to come and intentionally hack the LockManager�s hashmap object reservation and attempt to book an already locked record with a different lockCookie.

I think the only way the SecurityException can be thrown is if there are two different versions of clients, 1 client has a booking method that uses lockRecord, update, and unlock. Another client has a version with booking method that just calls the updateRecord without lock. And the SecurityException is thrown when thread 1 locked the record but before it can perform the updates, second client directly performs the updateRecord method.

Which I guess is possible if in future; another programmer decides to make change to the application and if he/she was careless and just decide to call the updateRecord method in its� booking method, instead of the lock, update, unlock steps.

What do you all think? Do you all have a something like checkLockingOwner method?

[Chandrakant Dhome]

Hi,
1. This is public method.
2. From description method's responsibility includes updating the record if lockCookie provided was the one originally used to lock it.
3. Public methods should not depend on checks in business logic calling them, most of all, ones modifying data.

So I think you should put a check and throw back an exception.