Database update notification

[Gilles Marceau]

Hi Ranchers,

i am wondering if the following use case is in the scope of the SCJD
assignement. This is about database update notification. Let's imagine
the use case :

1) Server is running.
2) Client A connects & displays the whole record list.
3) Client B connects & displays the whole record list.
4) Client A requests an updates on record #0.
5) Server updates record #0.
6) Client A updates the record #0 display.
7) Client B updates the record #0 display.

To have the step 7 working, we need an update notification mechanism
from the server to the clients (because otherwise client B won't know
that record #0 has changed). Another way to do this would be that each
client polls the server records periodically (not nice for me because it
means an increase of server load).

So my question is for people who are working on the assignment (did you
planned to manage this case ?) and also for people who passed the SCJD
(did you managed this case in your project ?).

In my opinion, this is in the scope, as the server is supposed to handle
multiple concurrent requests. A consequence is that the server have also
to notify each client of the update performed by other clients.

Thanks for your feedback.

Gilles

[ March 02, 2008: Message edited by: Gilles Marceau ]
[ March 02, 2008: Message edited by: Gilles Marceau ]

[mohamed sulibi]

hi;

To have the step 7 working, we need an update notification mechanism
from the server to the clients

it is not required for the project and in the real live. but when the client b attempts to update or book the same record that the client A
update , the server must response with an error indicated that the record
is already book or updated.

Best regards.
Mohamed Darim.

[Gilles Marceau]

Hello Mohamed,

could you please explain more why this notification mechanism is not
required in the SCJD project ? The software we are building for the
assignement use a client-server architecture and several client softwares
can run at the same time. It seems to me more user friendly that the client
GUI software update itself when the server data changes rather than forcing
the user to manually request an update.

Thank you for your feedback.

Gilles

[Gilles Marceau]

Anybody out there interested in contributing on this issue ?

Well, in the meantime i made several investigations, and i found that
the Monkhouse and Camerlengo's projet (taken from their book "SCJD Exam
with J2SE 5") doesn't handle the use case i described in this topic first
post. Each client is not notified of the updates performed by the other
clients. Each client has to do an empty "search" request to get the
up-to-date data.
I understand that the notification process add some complexity to the
project (and with the extra line of codes, extra opportunities to lose
some points). On the other hand, the idea to bring to a client (even a
fictional one) a GUI displaying out-of-date data makes me feel
uncomfortable.

Please let me know your opinion.

Gilles

[Alexander V Fahrmann]

I have an opinion! : If I have understood you
correctly you are going to implement each client
as an Observer of ... the Database (applying the
"push" model of notification) - do that if you wish
but imagine that there are thousands of clients...
are you going to force all of them to refresh
their last search results if some minor change
takes place in the database? What will happen
with trafic in that case?

P.S.: I am not going to implement the Observer mechanizm
in my solution.

[Gilles Marceau]

Hi Alexander,

you are right, this database notification mechanism is similar
to the Observer pattern. Indeed, there is a cost to implement a
notification mechanism, but the cost could be limited by using
a mixed pull&push model :
one can imagine sending after each database change an event with
a type (CREATE,UPDATE,DELETE), on the record number on which the
event occured. This is the push part.
Each client has then the responsability to request more information
from the database (for the CREATE & UPDATE type). This is the pull
part.

The other approach for the clients to keep synchronized with the
database would be to poll periodicaly (perform search and get the
whole database list). This approach creates more traffic that the
one described above (because client request data on the database
even if nothing change, and the requests are less focused).

If the requirement is to keep the clients synchronized with the
database (which is not explicitly the case in SCJD), one of the
solution above have to be implemented, and the traffic increase
is unavoidable, in my opinion. So for the thousands of clients...
well, run the server on a speed-light machine ;-).

On second though, i think i won't implement a database notification
mechanism neither. I will just take extra care with the currently
selected record (to ensure that when the record is selected, the
record data are up to date), and during update (read again the record
before update to be sure there will be no update(s) lost).

Thanks for your feedback.

Gilles

PS : RMI supports a callback feature to manage this kind of database
update notification process :
http://www.ryerson.ca/~dgrimsha/courses/cps841/RMICallbacks.html

[Steve Daskam]

Gilles,

Mohamed has the correct approach to handle this situation. I have worked on many projects and the preferred approach is usually to use optimistic locking, which means that if two users obtain the same record, and one updates, then the other updates (and fails), an error message is sent back to the second updater telling him that he needs to re-retrieve the data and try again. Typically, there is some kind of update value (such as an update-timestamp) that is checked to see if the retrieved record is still in sync with the record in the database. I hope that makes sense.

Regards,
Steve

[mohamed sulibi]

hi;

thunk you Gilles Marceau for the below link:

PS : RMI supports a callback feature to manage this kind of database
update notification process :
http://www.ryerson.ca/~dgrimsha/courses/cps841/RMICallbacks.html

thunk you Steve Daskam for providing clear description for this issue.

best regards.
Mohammed Darim.

[Gilles Marceau]

Hi Steve,

thanks for your feedback. I didn't know the concept of "optimistic
locking", but the way i am going to implement the client record update
is similar (read again before an update, and makes fail the update
request if the record data on the database is not the same than the client
record data before the update).

brgds,

Gilles