Server methods called by Gui

[Dmitri Christo]

Hi, it seems like I find it difficult to understand the idea of the gui calling methods on the server. I have seen conversations where people say this method or that method should be called on the server side rather on the client side.

My confusion is that as I understand all a Gui should have in network mode is a RMI stub with the given interface methods. Which I though meant that when I call that remote method from the Gui, it ultimately gets called on the server (remote). So all remote methods get called on the server side right?

That reasoning led me to think that separate gui clients, could not book the same record at the same time. However at this time it seems they can. I suspect the problem might be that I created the 'book' method locally (on client), although that method consists of remote methods such as read, lock, update, unlock. Any comments here? Is there here a fundamental misunderstanding of the concept? I can't tell if it an issue at the db layer or the gui layer at this time.

If anyone could help a bit with suggestions that'd be great.

[Roberto Perillo]

Howdy, Dmitri.

It's really hard to tell where is the problem, because we can't really look at your code. But, are you verifing if the record was already booked before booking it? Try this: initilize your server, then initilize a GUI in console #1, book a room, then initilize a GUI in console #2 (can be in the same machine), and check if you can see the room that was booked by console #1 appropriately. If you do, then I don't think you implemented the method on the client side.
This question is hard to answer, but I'm sure you'll find the problem and soon you'll be a SCJD!

[Dmitri Christo]

Hi Roberto, thanks for replying. It turns out that several things happen:

1) I update/refresh the table with the server only after a book, or un-book action has completed.
2) Before booking, I check if current record is booked or not (this is not refreshed data though), by looking at the owner field. If its empty, the user can go ahead and book, if its not, they can't book.
3) I didn't provide a way to check if a record is "in the middle of booking" by someone else. For example one client can have started the booking action, but is in the middle typing in the 8-digit owner id number, or takes a long time typing it in. During that idle time another user sees that record as empty. Even when doing a refresh, the user is notified if a record is booked and not if a record is locked. (I think this is the catch right here)

So, my guess is that in addition to checking the owner field, I should also check if the record is locked.

[Dmitri Christo]

...just want to add this: Even if I dont explicitly check if the record is locked, shouldn't my book method at least block if the record I try to book is under some other user's lock? The book method consists of lock-update-unlock methods and since those are remote, the lock part of the book method should block right?

I base this on the fact that with non-gui multiple clients my locking works fine.

[Dmitri Christo]

I am not sure what else to think of, unless the different dos terminals I bring up as clients, end up using the same thread? ... Is there a way to check that?

[Alex Belisle Turcot]

Originally posted by Dmitri Christo:
...just want to add this: Even if I dont explicitly check if the record is locked, shouldn't my book method at least block if the record I try to book is under some other user's lock? The book method consists of lock-update-unlock methods and since those are remote, the lock part of the book method should block right?

I base this on the fact that with non-gui multiple clients my locking works fine.

My advice would be to write a small prototype/proof on concept beside your assignment. No need for SWING/GUI..

Let say you have 2 clients using your remote object. These 2 clients are running in distinct Thread, 100% concurrently. When they contact the server, RMI does the rest:
[1] client1 -> getRemoteObj -> remoteObj.book() -> data.book()
[2] client2 -> getRemoteObj -> remoteObj.book() -> data.book()

When using your remote object, it is possible that the exact same thread is reused by RMI. This is because it is keeping a pool of threads. But there is however no guarantee, the threads could also be different.

I think if I were you, I would write some junit directly using the remote object's methods, by starting multiple threads accessing the same records...

You could then "step into" your code and "block" 1 thread at one point where it should hold the lock. And then "step into" with a second thread and see how it react. You might find some logic error...

Regards,
Alex
[ March 16, 2008: Message edited by: Alex Belisle Turcot ]

[Dmitri Christo]

Hi Alex, thanks for replying. Great advice as usual. The thing you brought to my attention was the RMI thread reuse, that is something I need to look into deeper.

But rest of the problem is actually solved. It wasn't really an error, more like a tricky design misconception. See, for example in Andrew's book, the user is prompted to do several things before the selected record is actually locked: The user sees an available room (even though data can be old), then clicks the book button, code enters the appropriate action listener for this button press and brings up a dialog for the user to enter the new owner information, the rest of the code then validates user's input, and if all is well at this point the record is finally locked! and then an update and unlock are called.

So what is the point to have the user do all these actions, like go for a seemingly available record and start entering new information if you dont have it locked already? What if the client thinks while entering the new data, that a book will be successful while in reality some other thread might have jumped in and finished working on that record already.

So, in my tests, I started 2 terminals and brought up two guis, selected same record and clicked the book button. For both users the dialog came up prompting them to enter new owner id for the same record! That was programmatically correct, since the code hadn't reached the lock method for that record yet.. Now I believe that is not a suitable behavior..
[ March 16, 2008: Message edited by: Dmitri Christo ]

[Dmitri Christo]

...the interesting thing here is that there are conversations like this
where they suggest the opposite...

Also, it's generally not advisable to lock a record at the point where a user starts to enter information and unlock it when they're done and the record is saved. Instead, let the user enter the new information and then let them confirm persisting the data. Only at that point should you lock, update and unlock the record.

Isn't the user 'tricked' in some way if they start doing a bunch of work on the record only to find they can't complete since that record is locked by someone else?
[ March 16, 2008: Message edited by: Dmitri Christo ]

[Alex Belisle Turcot]

Originally posted by Dmitri Christo:
So what is the point to have the user do all these actions, like go for a seemingly available record and start entering new information if you dont have it locked already? What if the client thinks while entering the new data, that a book will be successful while in reality some other thread might have jumped in and finished working on that record already.

The trouble is, if you have 100 clients and one of them books a record, would you propagate the new values to all the clients ? Your clients would have to be known by the server.. Or you could have the clients refreshing their data on a regular basis ? Otherwise, your clients will not have the necessary information to decide if the booking should go on or not, until they contacts the server and realise they did not have the latest values..

Many possibilities, with trade-off and pros & cons..

So, in my tests, I started 2 terminals and brought up two guis, selected same record and clicked the book button. For both users the dialog came up prompting them to enter new owner id for the same record! That was programmatically correct, since the code hadn't reached the lock method for that record yet.. Now I believe that is not a suitable behavior..

The fact is, until you lock the record, many clients could be working on the record. You could lock the record early in the process, but then the record would be locked for a long time. Or, you can lock the record a split second, only as you book, but then many clients would be "tricked" (as you said).

Isn't the user 'tricked' in some way if they start doing a bunch of work on the record only to find they can't complete since that record is locked by someone else?

In a way, the client is tricked, yea But the client is rather tricked in thinking he is working on the latest records...

I think it is OK to let the user start booking and entering its customer id. When he tries to actually lock/book it, the operation would throw an exception to let the user know.. This is at least what I did..

The exception is notifying the client that its data was "not in sync".. I only let a client book a record if the client record is a perfect match with the record in the database... Which means, if another client modified the record, it won't let another client modify it (booking is a subset of "modifying" a record).

I really think for this assignment, you should simply throw an exception letting the client know that booking was not performed because its data were not up to date. The client will then handle this exception, probably by requesting the records..

You can read about optimistic and pessimistic locking:

http://www.agiledata.org/essays/concurrencyControl.html#PessimisticLocking

Pessimistc: Pessimistic locking is an approach where an entity is locked in the database for the entire time that it is in application memory (often in the form of an object)

Pessimistic: .[..]Had a collision been detected, e.g. the data had been updated by another process after it had originally been read into memory, then the collision would need to be resolved.

http://blogs.msdn.com/ricom/archive/2004/06/24/165063.aspx

Optimistic locking -- that's where you assume things will go well and design your locks so that they handle conflicts as the exceptional case

Pessimistic locking -- the converse where you assume conflicts are likely and create some kind of reservation system where sections are locked while they are edited

[ March 17, 2008: Message edited by: Alex Belisle Turcot ]

[ March 17, 2008: Message edited by: Alex Belisle Turcot ]
[ March 17, 2008: Message edited by: Alex Belisle Turcot ]

[Dmitri Christo]

...much clearer now! Thanks Alex for the good advice.

[Adrian Engler]

Originally posted by Dmitri Christo:
...the interesting thing here is that there are conversations like this
where they suggest the opposite...


Isn't the user 'tricked' in some way if they start doing a bunch of work on the record only to find they can't complete since that record is locked by someone else?

[ March 16, 2008: Message edited by: Dmitri Christo ]

Yes, that may be the case, but the option that someone who keeps a record locked while going to lunch or going home is probably much worse. The effort for booking a record is probably not that big, so that users would probably put up with working on booking a record only for finding out that it has already been booked by someone else.

I solved this by making two checks: when a user selects a record for booking, fresh data for that record are loaded from the server, and if booking is not possible any more, the user is notified right away. If booking is still possible, the user can go on with editing (but the record is not locked), and when the data are saved, a second check happens (first a lock is obtained, then the data are read to make sure they have not been changed in a way that booking is not possible any more, and if the record data are OK, the booking is saved and the lock is released). That way, the record does not stay locked for a longer time, but people can only spend time for an update that will fail if they really do it at the same time and not if they just have stale data from an earlier search, but do not edit the record at the same time.

However, making two checks is probably unnecessary - the specification does not require it, and it may make the implementation unnecessarily complex.