URLyBird 1.1.2: Server-Side Locking Permissible?

[Alex Duran]

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:

public long lock(int recNo) throws RecordNotFoundException    

public void unlock(int recNo, long cookie) throws RecordNotFoundException, SecurityException    

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

https://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 ]

[Vincent Li]

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!)