Extending DB interface - doubts

[Kate Jackson]

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]

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.

[Roel De Nijs]

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

[Kate Jackson]

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]

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!