Write lock

[Adrian Yan]

According to the requirement, the locking and unlocking is a write lock. Should I implement the "lock, read, update, write, unlock" in my server code or client code?

[Jerry Pulley]

Adrian,
My requirements mentioned a client program that exposed all the public methods of the Data class, i.e. lock, unlock, modify, etc. I took this to mean that the server should provide a thread-safe and remote means to access those methods in Data, and that the client interface should use them to query and manipulate the server. In other words, I'd put the lock-read-modify-unlock sequence on the client.
Jerry

[Adrian Yan]

That's what I though too. Even thought the clients are exposed to all the public methods, it should be the client who respondible to ensure the locking. It also allow for future development.

[Sam Wong]

When you say client, you mean Data client and not the GUI, right? I would not want to perform the transaction sequence in the GUI code at all. Even if you use MVC pattern, it shouldn't exist within the controller, imo.
Sam

[Adrian Yan]

Of course, my client design is as follow:
1. a data client that has all the public method of the data.class, with additional methods to support the client booking, etc.
2. a simple GUI shell that will sit on top of the client, it calls the methods in the data client.

[Swapan Golla]

Is it safe to say then that controller sets the state of the model and then model is essentially the DataClient with all its accessor method and also information about the current state of the view.