• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Locking Requirements

 
Jason Boutwell
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am a bit confused by the wording of the locking requirement on the Dev specs. I hope someone can help clear it up.
The instructions seem to suggest that the public lock() and unlock() methods must be implemented in Data or a Data subclass.
Here is my server design:
DataIF interface implemented by Data class.
RemoteDataIF interface extends DataIF and Remote, implemented by RemoteData class. RemoteData extends UnicastRemoteObject.
My RemoteData class delegates locking calls to a private instance of LockManager, which contains the lock() and unlock() methods. It also delegates data access calls to a private Data instance.
Does this sound like it violates the assignment's criteria?
It seems to me that lock() and unlock() should not be exposed to the client through the Data or RemoteData interfaces. Locking is an implementation detail, irrelevant to a client.
Am I way off base?
Thanks in advance.
-- jason
 
Branko Paskutini
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jason,
Hope you are not off base, my design is exactly the same as yours
It would be good to hear from someone with more OO knowledge if we are breaking the rules or not.
Branko.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I did not implement lock() and unlock() in Data (alright, well, I added some validation of the record number) or a subclass. Instead, I implemented it in a LockManager called from a RemoteData (some call it Connection) object.
Passed with -- I think -- no penalty on design (my apologies, it was over two years ago).
But why are lock() and unlock() implementation details? It seemed to me that the requirements are trying to steer you away from implementing the business logic on the server, and you cannot implement it on the client without using lock() and unlock().
- Peter
 
Jason Boutwell
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter,
My own feeling is that it is not the client's responsibility to worry about locking, and therefore there is no reason for the client to have access to locking methods. The client's only job is to request information from a server and present it. The details of HOW information is retrieved (ie. database locking requirements) should be solely the server's responsibility, IMHO.
I have public lock() and unlock() located in a private LockManager, with private accessors to the LockManager in the RemoteData (Connection) object. The public interface methods, such as criteriaFind(), use the locking methods.
This seems to me to be clean and proper encapsulation and separation of responsibilites. While I plan to say as much in my design document, I don't want to violate any assignment criteria, which would make my design decision moot, because I will have already failed.
So I guess the question is: Will defining and implementing the public lock methods within a private LockManager instance pass muster with the specs?
Peter wrote: "It seemed to me that the requirements are trying to steer you away from implementing the business logic on the server"
I've always been taught that business logic on the client is bad design. You should be able to alter business logic without touching client code. At most, clients should be responsible for input data validation.
-- jason
 
Sai Prasad
Ranch Hand
Posts: 560
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The requirement document clearly says "Architecturally, the application is a traditional client-server system". In the traditional client-server system, the client is fat loaded with business logic. It doesn't mean that you have to have the business logic at the client side for this assignment.
Having said that, you cannot avoid calling lock/unlock methods from the client unless you create another interface that the client can call and hide the lock/unlock on the server side. In that case you are probably violating another requirement "This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration"
In my design, I have a LockManager similar to yours which acts as a Wrapper to the Data class to handle lock/unlock/modify/delete methods. I do make lock/unlock calls from the client.
 
Jason Boutwell
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess that I have been spending too much time with my head in the thin-client, EJB container world.
I'll just have to swallow hard and adhere to the spec word for word, whether I like it or not.
-- Jason
 
Branko Paskutini
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jason,
I don't think you need to call lock/unlock from criteriaFind(). It should be called only when you are doing db update.
 
Jason Boutwell
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Branko wrote:
"I don't think you need to call lock/unlock from criteriaFind(). It should be called only when you are doing db update."
You are correct. I was just using criteriaFind() as an example of a public interface method, without regard to its use of locking.
-- jason
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jason, I fully agree with you; I've done both fat-client and thin-client commercial projects. To sweeten the pill, consider that the Data mini-database engine is completely generic. Likewise, the multi-user database server you're building on top of it can be fully generic and reusable if you do a good job.
This would be rather different if the business layer migrated into the server -- the API exposed by the server would then be completely application-specific. Of course you and I know that it is well possible to build a generic database-engine-cum-application-server that allows the deployment of arbitrary business components, but the complexity would be appreciably higher.
- Peter
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic