URLybird (1.3.1): should i use lock/unlok for update in non-network mode?

[Steve Wang]

I have a question and wish to get some help from many java guru here.
I felt that there is no need to use Data.lock(recNo) before Data.update(recNo,..), and Data.unlock(recNo) after Data.update(recNo, ..). I am not quite sure although i believe so. Can anyone enlighten me please?

BTW - i did use lock/unlock for update in networked mode.

Thanks in advance.

[Andrew Monkhouse]

Hi Steve,

You are right - in non networked mode, there is no chance of another client modifying the records, so locking is not needed.

Many people do lock the records anyway, as that means that the code is identical for both networked and non networked modes. In fact, you may even be able to use the same code for both modes, ignoring which mode you are in.

Regards, Andrew

[Steve Wang]

Thanks, Mark, for comments.

So which way do you think better for the purpose of exam?

i implemented no-lock's update for non-networked mode. It seems there is a little more code compared with what you mentioned above.

[Javini Javono]

Hi,

As Andrew stated:

Many people do lock the records anyway, as that means that the code is identical for both networked and non networked modes. In fact, you may even be able to use the same code for both modes, ignoring which mode you are in.


Thus, if you decide to have slightly different code for the different mode, then your business
methods become, in my opinion unwieldly when you develope your GUI client application:

LocalData      localData = null;
RemoteData   remoteData = null;
 
if (user requested local connection) {
    //Code block almost identical to below, but slightly different.
} else if (user request remote connection) {
    //Code block almost identical to the above, but slightly different.
}

There is probably little doubt that having a connection which allows
the client application to not care of what type is best:

IndependentDataInterface     data = null;
 
if (user requested local connection) {
   data = ...;
} else if (user requested remote connection) {
   data = ...;
 
//Now only one code block is required to carry out the business
//method, regardless of whether the connection is local or remote.
 
String[] fields = data.read(10);

thanks,
Javini Javono

[Steve Wang]

In my application, I have one interface like "IndependentDataInterface" from client side to polymorphycally call DataAdapter's methods. I used a Decorater pattern here to delegate calls inside the class "RemoteDataAdapterImpl" to the class "LocalDataAdapterImpl" (a kind of technique used in Java I/O hierrachy).
So bookRoom method
1). for class "LocalDataAdapterImpl' is simply like (no lock/unlock is invloved):
Data.update(...)
2). For "RemoteDataAdapterImpl" has to be different by adding lock/unlock functionalities like:
Data.lock(recNo)
Data.update(...) // or could delegate to "LocalDataAdapterImpl" update(..) method.
Data.unlock(recNo)

I agree with Andew, that from OO design viewpoint, lock/unlock must be used in "LocalDataAdapterImpl" for non-networked mode. On the other hand, from the assignment specification, lock/unlock should NOT be used for lock/unlock since only ONE client is assumed to use the system, as far as lock/unlock overhead is concerned for non-netowked mode.

Any brighter ideas here, please advise, ranchers! Thanks.

[Andrew Monkhouse]

Hi Steve,

On the other hand, from the assignment specification, lock/unlock should NOT be used for lock/unlock since only ONE client is assumed to use the system, as far as lock/unlock overhead is concerned for non-netowked mode.

I think it is better to say that in non network mode, locking need not be used rather than should not be used.

The overhead of locking the record is minimal, especially when running in standalone mode (since you are not competing for locks ) so I do not think that is enough of a reason to avoid it.

But the advantages of having one set of code to read / write / maintain are great. And it ensures that anyone working on this assignment automatically starts thinking in terms of locking records before doing updates - regardless of whether they are working on standalone or multi user systems. There is no stopping and thinking about which mode you are coding for.

In the end though, this is just another design decision you will have to make (and document ).

Regards, Andrew
[ May 23, 2004: Message edited by: Andrew Monkhouse ]

[Steve Wang]

Hi, Andrew -- i am a little confused with what you described above. Do you mean that I need only one class for both remote networked and local non-network modes? Whatever OO patterns you use, you have got to somehere to tell the difference between remote and local mode, more or less. Through inteface reference, we may polymorphically invoke appropriate methods.

If you think, that i still need two classes "RemoteDataAdapterImpl" and "LocalDataAdapterImpl" to implement appropriate interfaces, the only way to elimiate the duplicated code for bookRoom method is to use lock/update/unlock in the class "LocalDataAdapterImpl", and use delegation to this class inside "RemoteDataAdapterImpl".

Please make it clearer!

[Andrew Monkhouse]

Hi Steve,

I am a little worried about describing this further, as I don't want to push you into a solution that you don't agree with. So please decide for yourself whether this is what you want to do.

My personal belief is that the business logic should be network neutral. Therefore my business logic looks something similar to:

    DatabaseInterface db = null;
 
    constructor(...) {
        if (connectionType == local)
            db = localConnection(...);
        } else {
            db = remoteConnection(...);
        }
    }
 
    public void bookRecord(...) throws AlreadyBookedException, DataAccessException {
        // initialisation
        db.lockRecord();
        // validation
        db.updateRecord();
        db.unlockRecord();
    }
 
    // other methods

Note that both those exceptions are my own, and neither of them are RMI specific.

The trick here is to make an adapter for the remote connection so that it implements a common interface, and wraps the remote exceptions inside my network neutral exceptions.

This means that I have one set of code for the business logic, which is run in both local and remote modes.

Regards, Andrew
[ May 24, 2004: Message edited by: Andrew Monkhouse ]

[Steve Wang]

Thank, Andrew.
I understand what you described.
I used a different strategy. I implemented a MVC pattern on client side (GUI). My BrokerModel contains a reference of IndependentAdapterInterface which polymorphically invokes on bookRoom method etc. This reference does not care which implementation is between RemoteAdapterImpl and LocalAdapterImpl. My RemoteAdapterImpl was implemented using a Decorator pattern.

I do not disagree with you. Your suggestion is one way out. Thanks for your precious input.

- Steve