Trouble understanding the Data.java logic

[Derick Potgieter]

I`m having trouble with the whole logic of the file. I have implement the following class

 
package suncertify.db;
 
public interface DB
{
  // Reads a record from the file. Returns an array where each
  // element is a record value.
  public String[] read(int recNo) throws RecordNotFoundException;
 

  // 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 update(int recNo, String[] data, long lockCookie)
    throws RecordNotFoundException, SecurityException;
 

  // Deletes a record, making the record number and associated disk
  // storage available for reuse.
  // Throws SecurityException if the record is locked with a cookie
  // other than lockCookie.
  public void delete(int recNo, long lockCookie)
    throws RecordNotFoundException, SecurityException;
 

 
  // Returns an array of record numbers that match the specified
  // criteria. Field n in the database file is described by
  // criteria[n]. A null value in criteria[n] matches any field
  // value. A non-null  value in criteria[n] matches any field
  // value that begins with criteria[n]. (For example, "Fred"
  // matches "Fred" or "Freddy".)
  public int[] find(String[] criteria);
 

  // 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;
 

  // Locks a record so that it can only be updated or deleted by this client.
  // Returned value is a cookie that must be used when the record is unlocked,
  // updated, or deleted. If the specified record is already locked by a different
  // client, the current thread gives up the CPU and consumes no CPU cycles until
  // the record is unlocked.
  public long lock(int recNo) throws RecordNotFoundException;
 

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

now my problem, to for instance update a record i have to provide a cookie.
but i can only get a cookie if i execute lock(recno). so should i create another class, implement the exact same methods and then have something like the following code??

  Data db = new Data();
  
  public void update(int recNo, String[] data)
        throws RecordNotFoundException, SecurityException{
    long cookie = db.lock(recNo);
    db.update(recNo,data,cookie);
    db.unlock(recNo,cookie);
  }
 

would this be right, or should i have the lock/unlock in my main data class. They way i`m doing it will work, but i does`nt look right.
using sun`s provided interface class then i create my own Data.java class
that implements that class, and now i`m creating a third class that looks they same as the sun interface class to actually lock,update,unlock.

Thanks
Derick

[Jon Entwistle]

Hi Derick,

OK... what you are describing is creating a proxy class on the server which has the same methods as Data but without the lock/unlock method - in other words you are hiding the need to lock/unlock from clients.

I know from reading other threads that people have passed the exam by following this strategy, although I personaly do not like it. My problems with it are twofold. First off, by hiding the lock/unlock from clients you are enforcing a locking strategy. This may be OK for the scenario we are given but who knows what locking strategy future clients will want/need to enforce? Secondly, I may be wrong but if Sun felt it important enough to include the cookies in the method signature, this says to me that they too important to hide at the first opportunity.

Your alternative is to pass the resposibilty for the locking through to the client, who must of course follow the (documented) need to follow the lock/update/unlock procedure.

These are just my thoughts on it, although I would say that you should go with whichever method you would be most comfortable justifying/defending.

Cheers,

Jon

[Baruch Sadogursky]

The option of passing the locking responsibility to the client brings a lot of complexivity to the application. Once you follow that strategy, you should track inactive/disconnected clients, in other words, make your server stateful.
On the other hand, by using a proxy or a facade you make the locked operations atomic, which release you from the need of mantainig conversation state with the client, makes your life easier, the application simplier, and once you'll want to change the locking strategy, you can switch the facade, or get rid of it totally.

[Andrew Monkhouse]

Hi Derrick,

I think you have missed the value of the lock methods: specifically they are there to stop two clients from booking the same record.

Consider the following scenario:

Client A requests a list of all records

Client B requests a list of all records

Client A can see that record 5 is not yet booked

Client B can see that record 5 is not yet booked

Client A updates record 5 to book it

Client B updates record 5 to book it

In this case, there was nothing to stop the two clients booking the same record.

So how are you going to stop this? I am leaving this as an exercise for you - we will eventually get to a solution where locking works for you .

By the way, could you please remove those ll's from your displayed name to meet the JavaRanch Official Policy On Displayed Names, which requires your displayed name to be a real name. You can change it here.

Thanks and regards, Andrew