aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes URLyBird 1.1.2: Server-Side Locking Permissible? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "URLyBird 1.1.2: Server-Side Locking Permissible?" Watch "URLyBird 1.1.2: Server-Side Locking Permissible?" New topic
Author

URLyBird 1.1.2: Server-Side Locking Permissible?

Alex Duran
Greenhorn

Joined: Jan 29, 2007
Posts: 8
I'm currently attempting to complete the programming assignment for URLyBird 1.1.2 and I am grappling with what is probably the most basic design question:

When the application is operating in true client-server mode (i.e. client-side GUI in one JVM makes RMI calls on a remote object in a separate JVM - aka the Server) - is it OK to implement a design where "lock" and "unlock" methods ARE NOT invoked by the client-side GUI.

In other words, I'm favoring a design where the remote interface does not resemble the suncertify.db.DB interface with RemoteException added to the method signatures. Rather, this remote interface would look like a business object (methods would have names like "bookReservation", "queryAllReservations", "queryReservationByHotelName", etc.).

I believe this design is also called "Thin-Client". Although this design requires changes in two abstraction layers (business object and client) when another business operation (such as deleting a reservation) is added later, I think I can justify the design because it insulates the client-side GUI from the data access implementation.

Has anybody passed URLyBird 1.1.2 using server-side locking/thin-client design without losing a lot of points in the locking section?

By the way, in URLyBird 1.1.2 the lock and unlock signatures look like:




I tried to get an answer from this thread before posting this question:

http://www.coderanch.com/t/184224/java-developer-SCJD/certification/Should-lock-methods-callable-client

But I just couldn't find an answer in the 140 posts. I tried, really I did!

[ February 05, 2007: Message edited by: Alex Duran ]

[ February 05, 2007: Message edited by: Alex Duran ]

[ February 05, 2007: Message edited by: Alex Duran ]

[ February 05, 2007: Message edited by: Alex Duran ]

[ February 05, 2007: Message edited by: Alex Duran ]
[ February 05, 2007: Message edited by: Alex Duran ]

SCJP
Vincent Li
Greenhorn

Joined: Jan 12, 2007
Posts: 22
Hi,

I don't see why not. I may not have pass it yet, but I think reading some of the other post of those who did (including the recent one from Kasper with 400/400), it sounds like that's what he did.

From a design point of view, you really don't want to expose ANY of the low level DB interface to the client. In my implementation, those are completely hidden from the client. It only knows how to search and book/unbook records. That's 2 methods, and they are also abstracted and does not deal with any of the String[] stuff. Those are all handled on the data access side.

By hiding the lock/unlock calls, you save yourself the problem of client locking a record but fail to unlock it for whatever reason, intentional or unintentional. As well, it allows you to keep the lock for the minimal amount of time.

-- Vince
SCJP(1.4), SCWCD(1.4), SCJD(almost there!)


Vince<br />SCJP(1.4), SCWCD(1.4), SCJD (5.0)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: URLyBird 1.1.2: Server-Side Locking Permissible?