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.
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.
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:
There is probably little doubt that having a connection which allows the client application to not care of what type is best:
thanks, Javini Javono
posted 16 years ago
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.
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 ]
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".
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.