wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes URLybird (1.3.1): should i use lock/unlok for update in non-network mode? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "URLybird (1.3.1): should i use lock/unlok for update in non-network mode?" Watch "URLybird (1.3.1): should i use lock/unlok for update in non-network mode?" New topic
Author

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

Steve Wang
Greenhorn

Joined: Jun 27, 2003
Posts: 18
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
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11490
    
  95

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


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Steve Wang
Greenhorn

Joined: Jun 27, 2003
Posts: 18
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
Ranch Hand

Joined: Dec 03, 2003
Posts: 286
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:



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
Steve Wang
Greenhorn

Joined: Jun 27, 2003
Posts: 18
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
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11490
    
  95

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
Greenhorn

Joined: Jun 27, 2003
Posts: 18
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
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11490
    
  95

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:



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
Greenhorn

Joined: Jun 27, 2003
Posts: 18
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: URLybird (1.3.1): should i use lock/unlok for update in non-network mode?