This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Extending DB interface - doubts Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Extending DB interface - doubts" Watch "Extending DB interface - doubts" New topic
Author

Extending DB interface - doubts

Kate Jackson
Greenhorn

Joined: Jan 12, 2010
Posts: 13
Hello,

I'm doing B&S (with lockCookie). I've searched this forum and I know that many of you extended the provided DB interface and passed.
I'm about to create a thin client (business service) and RMI networking so I will probably just follow suit.
Of course, I realize this assignment is more like a student project not a real life situation. That's why we have incomplete specification and the need for choices.txt.

Having said all of that, what if the assessors were to test our server with their own client based on DB interface only ?
In general we're supposed to program against interfaces, right ?
In other words, aren't we supposed to implement this DB interface in a way that ensures the other client will work just as well ?
For example when we add read/save for caching or setClientId/getClientId for RMI client identification, this other app will only use the DB interface thus will probably not work (or even worse make a total mess).
On the other hand, I can't seem to find a way of reasonable locking implementation (deadlock, double lock prevention) using sole DB interface. Using RMI I can't rely on client identification by executing Thread.

Or perhaps, is there a way to stay with interface provided and my planned implementation (thin client, business service, RMI) ?
Can anybody give me some food for thought ?

Kate

EDIT: Yes I know - I should stop thinking too much and get it over and done with ;)

Anayonkar Shivalkar
Bartender

Joined: Dec 08, 2010
Posts: 1502
    
    5

Hello Kate Jackson,

Welcome to CodeRanch!
Kate Jackson wrote:what if the assessors were to test our server with their own client based on DB interface only ?

First of all, there's only one application jar. Its not like separate server and client jars. So, if somebody wants to test your server with their client jar, frankly speaking, its their problem. You would provide javadoc for your code, which is supposed to be read by them et-cetera.
But anyways, is this a MUST requirement? That your server MUST work with somebody else's client? If not, then please stop thinking about it.
Kate Jackson wrote:Or perhaps, is there a way to stay with interface provided and my planned implementation (thin client, business service, RMI) ?

Well, did you face any issues during implementing the application with thin-client, business service and RMI approach? Please TellTheDetails.


Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5126
    
  12

Kate Jackson wrote:what if the assessors were to test our server with their own client based on DB interface only ?

That will never happen, they just execute your runnable jar you must provide when you submit your assignment

Kate Jackson wrote:In general we're supposed to program against interfaces, right ?

That's indeed a good coding practice

Kate Jackson wrote:aren't we supposed to implement this DB interface in a way that ensures the other client will work just as well ?

You should produce a working implementation of each method in the given interface. But you can provide extra methods (when you extend the given interface) to make the program work flawlessly. That's something I did and I passed, you have of course to justify these decisions in your choices.txt. What you can't do, is extend the given interface with a whole bunch of new methods, implement these and provide no implementation (e.g. throw new UnsupportedOperationException()) for the methods in the given interface.

Kate Jackson wrote:setClientId/getClientId for RMI client identification

That's something you won't need, because you have the lockCookie to identify each client uniquely.

Kate Jackson wrote:is there a way to stay with interface provided and my planned implementation (thin client, business service, RMI) ?

No, that's impossible. The methods described in the given interface are no business methods (book, find,...) so you'll need to provide an extra business service. Even if you would have opted for a fat client, you'll need some extra interface, because the methods in the given interface don't throw a RemoteException (which you definitely need when working with RMI)


Hope it helps!
Kind regards,
Roel


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Kate Jackson
Greenhorn

Joined: Jan 12, 2010
Posts: 13
Roel De Nijs wrote:
Kate Jackson wrote:setClientId/getClientId for RMI client identification

That's something you won't need, because you have the lockCookie to identify each client uniquely.


It would be nice if my Data implementation prevented client from locking more than 1 record at a time (especially locking the same record twice), deadlock occurring in case of cross-locking 2 records by 2 clients and situations like that, but I can't seem to find a way of doing that with RMI and sole DB interface (how would I know which client called the lock() method ?)
Obviously with my business service layer it shouldn't be a problem and there will be no other clients using DB interface directly.


Roel De Nijs wrote:
Kate Jackson wrote:is there a way to stay with interface provided and my planned implementation (thin client, business service, RMI) ?


No, that's impossible. The methods described in the given interface are no business methods (book, find,...) so you'll need to provide an extra business service. Even if you would have opted for a fat client, you'll need some extra interface, because the methods in the given interface don't throw a RemoteException (which you definitely need when working with RMI)


I'm fine with business method, however I just think that extending the DB interface is not something I would expect in a real life situation (which obviously is not the case here).
Anyway, I'm planning to stay with the interface provided for my Data implementation (with a business service on top of it), though it might get a little bit tricky.
I hope I'm not taking the road to 'kiss my $300 goodbye'


Roel De Nijs wrote:
Hope it helps!


Sure it does, keep up the good work here
thanks
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5126
    
  12

Kate Jackson wrote:It would be nice if my Data implementation prevented client from locking more than 1 record at a time (especially locking the same record twice), deadlock occurring in case of cross-locking 2 records by 2 clients and situations like that, but I can't seem to find a way of doing that with RMI and sole DB interface (how would I know which client called the lock() method ?)

That's impossible to know when your interface has a lockCookie. You simply can't know how many records a given client has already locked. That's one of the differences between the interface with a lockCookie and without a lockCookie. I had an interface without a lockCookie and could prevent a client locking more than 1 record at a time. I know people with a lockCookie-interface passed by just documenting (javadoc and/or choices.txt) the appropriate use of the API (given interface) and thus make sure a client doesn't lock more than 1 record at once or lock the same record twice. You are the developer of the application, so you will use your own developed API correctly, so no issues here


Kate Jackson wrote: I'm planning to stay with the interface provided for my Data implementation (with a business service on top of it), though it might get a little bit tricky.

Nothing tricky here: tons of people followed this approach and passed!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Extending DB interface - doubts
 
Similar Threads
Why Swing client at all?
Terminology Clarification
RMI and Threading
Multi-threading programming: we do not need lock() unlock() at all
locking - why do we have to identify the client?