Colin Yates

Ranch Hand
+ Follow
since Dec 16, 2004
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Colin Yates


Any abstract, vague pointers to help the rest of us. Particularly with respect to your fantastic 80/80 locking score!

17 years ago

Thanks Frans, and Paul
[ March 04, 2005: Message edited by: Colin Yates ]

I am still not sure how that will prevent clientB using clientA's cookie!

The scenario of clientA gets cookie123 for recordA, clientB somehow magically guesses that recordA's lock is cookie123 and is then clientB is free to update recordA!

Based on everyone's replies, it seems pretty safe to drop the "specific client" restriction and just ensure that the same cookie value is used.

How have other URLyBird people resolved this client specific problem?


Apologies, I thought I had specified the methods

They are:
// Locks a record so that it can only be updated or delted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated or delted. etc.
public long lock(int recNo);

So returning the cookie isn't a problem, it is making sure that only the client who called lock for any given record can call unlock for the same record.

Maybe I am going too far with this and the "client specific" thing doesn't need to be implemented, so if clientA happens to know the cookie that clientB has for recordA then clientA *can* do things with recordA.

Even if I follow Andrews advice and create a new dedicated object per client, what happens if that object (because it is a remote object) times out? Another one would be created and all the previous locks would be orphaned.....
Thanks Paul,

The second link ( contains some excellent comments made by Andrew which seems to support my concerns, and also provides an answer.

Just to be clear, are you saying it doesn't matter that the cookie could come from a different client as long as it is the same cookie that the server has associated with that record? i.e.:

clientA locks recordA and gets cookie1
clientB updates recordA with cookie1
recordA is updated

And you know for definate that people have passed with this approach Maybe my understanding of English is incorrect, but I do not see how that is compatible with "Locks a record so it can only be updated by this *client*"

Thanks Paul.
Hi Paul,

Unfortunately your solution won't work.

The criteria isn't that the *cookie* is the same as returned by unlock, but the *client* is the same.

Imagine, you lock recordA, and get cookie xyz, you ring me up, tell me what xyz is, I can then connect to your server using the appropriate cookie. the cookie is the same, but the client is different.

See what I mean

The URLyBird Data.lock() method states:

"Locks a record so that it can only be updated or deleted by this client...."

How *on Earth* are we supposed to implement this so it knows which client you are? Assuming (incorrectly) that RMI gives you a unique way to determine the client, it would still mean having an RMI enabled class and non-RMI enabled class.

I did think about using the strategy pattern (is that the right one) to determine the client's id, and have the RMI server give out a new id to each client. The question is then how does the Strategy implementation work?

Has anybody just ignored this "client specific" requirement and passed?


First off, we are not righting a large, multi-user app, we are writing a solution for an abitrary, and quite unrealistic spec.

Second, I don't read all the records, I ask the server to give me a String[] of all the unique names, and another String[] of all the unique locations. To rephrase, the server compiles a *cached internal to the server* list of unique names/locations and sends the list to the client in one chunk.

You absolutely do need to do this *at some point* because someone else could have modified the database so your local list of unique names is now out of date. Rather than leave that up to the user to decide when to do it, I decided to do it for them.

To be honest, my commercial mind just cannot imagine users from around the world using this app
I don't think the requirements ask you to allow them to explictly cancel the reservation so don't implement this as it is beyond scope.

I also made the decision (and documented!) that only one customer can reserve a room. If I booked a 4 bedroom hotel room and turned up to find you in it as well, I would not be best pleased. No offence

Basically do the *absolute* minimum you can sensibly do to pass. They are not expecting you to write a real world application, only to satisfy their somewhat artificial requirements.
JCombo boxes (in themselves) do not satisfy the "must be exact" because the records in the database can have changed since the combo boxes were constructed.

clientA: populate combo with distinct(name)s {nameA, nameB, nameC}
clientB: modify nameA to nameAAA
clientA: find all nameA

the 3rd operation will return all records with nameA <strong>and nameAAA</strong>

I resolved this by having the client do the following:

- find all matches
- for each matched recordId
- read the record from the server
- if it has been deleted, continue
- if it is no longer an exact match continue
- great, it is still a valid match

Also, remember, you need to refresh those lists of combo boxes regulary. I do it evertime the user clicks a search

I think I am getting a bit too obsessed with tis whole MVC thing.

First off, I have a mainGUI which displays search criteria and search results. I expose the buttons and search criteria (combos) via getters. In my controller I add a listener to the button and then call my[]).

All well and good.

I also have a reservationGUI which displays a single record and allows you to book it. I have a reservatonController and reservationModel. The mainController will construct a new reservationController everytime you click the reserve button (assuming you have selected a row in the table).

OK, all standard stuff.

Now my questions

The reservationGUI should start off disabled until it has acquired a lock. The reservationModel fires events which the GUi listens to (i.e. recordLocked()). Should the controller listen to these events and then enable/disable the relevant components on the reservationGUI, or should the GUI itself? It seems to be more of a GUI thing to me?

The reservation code has some validation logic associated with it, i.e. it has to be between 1 and 8 characters long. Should the controller add a listener onto the field and enable/disable the button, or should the GUI doe this by default?

After the reservationGUI closes, assuming they have booked the reservation, how does the mainGUi get updated? Should the mainGUI also listen to every instance of reservationModel, or should the mainController listen?

The question really is how much logic goes into the GUI? On the one hand you could write a GUI which is very self contained, and exposes implementation agnostic aware methods like String[] getCriteria() and onReservationEvent(int selected rowNo), or you could have an incredibly dumb GUI which does nothing more than layout components. In this case the controller must then add logic (i.e. validation logic, actionListeners etc) to the GUI and the GUI must expose all of it's internal workings.

Help The consensus seems to be to have an incredibly dumb GUI and make the controller *very* aware of the GUI's internal workings.
Right, so the "controller" isn't the business logic facade. The controller maps GUI events to the facade? Is that right?

I think I am probably complicating things because I always have a callback interface for the respective GUI which the GUI calls on it's actionListeners. So for example, I would have a {
public static interface EventHandler {
void onSearch();

public String getLocationCriteria() {}
public String getNameCriteria() {}
public void addEventHandler(EventHandler handler);

To "use" the GUI now involves:

final GUI gui = new GUI();
gui.addEventHandler(new Gui.EventHandler() {
public void onSearch() {

I suppose my EventHandler is the controller?

I was getting confused thinking the "Controller" was GUI agnostic, and could live on the server side. Would it be more correct to state:

- Facade is view agnostic and could live on server side
- Controller, View and Model are all GUI objects

So for example, the model isn't the database, it is the current data set the view is working for. So after executing a search, the model only contains the search results.

Is that correct?

Thanks Max. Great book BTW. I know I am doing a disservice to your book by asking these questions, I just want to make sure Ihave the right terminology. I am a J2EE/web gui so thick swing clients are a bit new
Maybe I can rephrase the question then:

Would someone please answer "" for 10 huggy points
Any ideas?

Essentially I am asking whether the controller can be aware of Swing, or whether ther controller should provide business methods and an Adapter ties the swing events to the controller's business methods?

Fair enough

I wouldn't actually expect the service to modify the code, but I don't see anything wrong with reviewing a set of design notes + code and providing pointers, i.e. have you thought about the design pattern XYZ.

The difference between the sun certified developer exam and a school exam is that the school exam is closed, the developer exam isn't. We are perfectly allowed to use forums such as this one, google, wiki's etc to research.

I suppose what I was suggesting would come under the "guided research" allowing the instructor to give appropriate feedback.

I am not sure I see the difference then reading/following some of the (very excellent) books out there, for example I am following Max's "The Sun Certified Developer Exam".

Both the "here is an solution to an abstract(ish) problem" and "here are abstract guidelines for your specific situation" work for me

My motivation was to actually reward the forum gurus for their excellent hard work