Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Contractors and the server

 
Tankred Smult
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!
I'm doing the Contractors assignment (ver: 2.3.2). I have created a Facade for the Data - class. The facade handles the locking so that the clients do not have to think about this. The facade provides only the tasks the GUI-client will have to perform, and the interface, which basically are these methods:
find
reserve
the reserve method will then lock the record, check that it is reservable, and then reserve the record.
This Facade is my remote object, e.g. the client is never able to directly lock a record. I think this is a good solution for several reasons.
However, now I've started fine-reading my assignment, and then I read
Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above.

Does this mean that the remote object has to have a lock/unlock method? Or is it sufficient to indirectly provide the lock/unlock functionality as I have done?
Will doing it my way lead to
Automatic Failure
?
Have anyone actually done something simular to what I've done and got away with it (not autmatcially failed)?
 
Mike Southgate
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm doing the same assignment (version 2.2.3) and I've interpreted this to mean the server must do the locking. I imagine they have a class written to run multiple threads on the server and expect to get specific results...
ms
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tankred, Welcome to JavaRanch.
Actually you design of the Facade is correct, and you will not have a lock or unlock method in this class.
What you might not have gotten to is one more level of redirection/decoupling/interface that the Facade will call that is on the server. This is your remote implementation of DBMain. Now in my case, I had a second interface called DataAccess that actually extended my DBMain interface. I added three interface methods in this new interface.
So what that means is your new "DataAccess" remote implementation will call the lock and unlock methods of the Data class on behalf of the clients. This is what the requirements are talking about.
Now you should also look into the LockManager class that you will find lots of posts about in this forum.
But I'll let you find them as you progress through the assignment. You got to have some fun, right?
Good Luck, and keep posting your questions, we all love helping.
Mark
 
Tankred Smult
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, what I have done is I've made the DataFacade the remote object, which means that in the code on the client there will never be a call to any lock-method. This is because the DataFacade lives on the server, and not in the client, so no lock-methods are available on the client.
My question is; is this a violation of the requirements?
I think one interpretation of the requirements is that the remote object has to have a lock/unlock method, and in that way "provide locking functionality as specified in the interface provided above" (which refers to the DBMain interface).
I'm unsure whether or not one could say that the DataFacade "provide locking functionality as specified in the interface provided above" by actually calling the lock/unlock methods in Data, but hide this from the client. (Which is the way I've done it). Any thoughts?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic