Thick vs thin client and lock lookie

[Paweł Baczyński]

I have URLyBird 1.2.3. It comes with a lock cookie in Data class.
Do I have to write a thick client? I was planning to write a thin one but now I'm not sure.

Does this make any sense?

//business logic class
Data db = ...
...
public void book(long recNo, String clientId) {   
   String[] update = ...
   long cookie = db.lock(recNo);
   db.update(recNo, update, cookie);
   db.unlock(recNo, cookie);
}

I omitted try-catches and throws clause to make an example simple. If I use lock cookie on server side only, why bother with it (except that implementing it is a MUST requirement)?
Maybe it really is better to write a thick client in this case?

[Roel De Nijs]

There is a very nice (and long) discussion about should lock methods be callable from the client. Summarized: all solutions should implement a thick client (based on a particular interpretation of 1 of the must requirements). But many people already passed with a thin client approach (me included). My assignment had no lockCookie, but I believe there are already quite a lot of people with such a cookie and passing the certification using a thin client approach.

From the "could I fail"-perspective: is there any must requirement which states you can't use a thin client approach? I guess there is no such a requirement, so it's safe to follow this approach. Even with a thin client you need to bother with the lockCookie to prevent 2 clients from updating the same record simultanously. That is no different with a thick client approach.

[Paweł Baczyński]

@Roel
That's a nice thread. I've read it and I'm still not convinced.
The only thing that could possibly convince me to use 2-tier is if it was a must requirement.
As you said it is not as you and many others passed with it.
My only concern was this lock cookie. If I put a locking into a server then the cookie would be completely unnecessary.
But choosing two-tier would introduce many problems. For example:
1. findByCriteria and readRecord
If I do this on client side I would need to verify the result on the client side (a record might be modified between calling of find and read). Why would client ever wanted to verify the output from the server?
That would mean checking the same condition twice (once on the server and once on the client) and I think it's not good idea.
I could create findAndGet method on then server side...
But if I do this (add a method to provided interdace) why not just introducing book and using it instead of lock/update/unlock?

2. Client crash before unlock.
3. Client needs to know how to translate String[] into Room...

If you knew that all solutions should implement a thick client why did you write a thin one?

[Roel De Nijs]

Pawel Pawlowicz wrote:If you knew that all solutions should implement a thick client why did you write a thin one?

Like you could read in the thread it's based on a particular interpretation of a statement in the instructions. Andrew is a native English speaker which I am not (and based on your name I don't think you are either, but that's a long shot), so I have a complete other interpretation of that specific statement. The thin client approach is easier to implement and maintain than a thick client (which I also mentioned in my decisions document). And finally, there isn't any must requirement which clearly states that a thin client isn't allowed.

As I said before it doesn't matter if you choose thick/thin client, the lockCookie will be needed in either approach to have a correctly functioning application.

[Paweł Baczyński]

Roel De Nijs wrote:Andrew is a native English speaker which I am not (and based on your name I don't think you are either, but that's a long shot)

You guessed right

[Himai Minh]

Pawel Buddy,
There is no requirement you must use thin/thick client.
The pros to use thin client is that if your client has lower computation power, using thin client is good as the server will handle most tasks.
The cons to use thin client is that the server will have more workload especially when handling multiple threads of clients.

The pros to use thick client is that if your server has lower computation power, your clients will handle most tasks. If your server loses power, your client can continue to finish it tasks and wait until the server is up again
The cons to use thick client is that if the client may send an object with more data to the server. More data will cause heavier network traffic.

No matter which approach you take, document it in your choice.txt.

[Dennis Grimbergen]

I used a thin client with a lock cookie. I never thought about the idea to use lock and unlock client side. I just exposed a book method to the client. The server is supposed to handle multiple concurrent requests and uses a logical locking mechanism for that (as was required for this exam). Why let the client control that?

As long as you can argument why you chose a certain solution (with pros and cons), then you're fine.