|
From: | Syan Tan |
Subject: | Re: [Gnumed-devel] middleware upgrade |
Date: | Thu, 22 Dec 2005 08:26:29 +0800 |
xmin piqued my interest again in distributed shared memory topic, and I went back and read about
sequential consistency equivalence. The book was mainly concerned about peer to peer systems,
and not so much client server systems, where communication is like a cobweb rather than wheel and spoke.
some concepts coming out of it:
- is a DSM (distributed shared memory) protocol write-invalidate or write-update ? If write update, the writer blocks until all other copies
on other clients are updated, whereas in write-invalidate, the readers are notified by replica managers that
they have invalid copies, and must refetch their data.
communication delay is a big problem in peer to peer , as it complicates
consistency models , because everyone has to acknowledge a communication in order for total ordering
to appear the same for everyone ( the order of updates, appear in the same sequence for everyone).
gnumed is client -server, and uses postgres client-Listen-block / server - Notify system in order
to implement DSM de facto . This means that in this specific function, gnumed is not single threaded ,
as it has to spawn a blocking thread that listens for updates, and when updates arrive, place a message
on wxwindows event queue to then place a message on the gmDispatcher single threaded event notifier.
(the wxwindows message command is thus a synchronized entry into the single main thread of gnumed's
execution).
Is postgres's notify command blocking for the server ( server blocks waiting for
aknowledgement of notify from all clients) ? It probably should be, because all active clients need
to acknowledge receipt of a single notify in order for total ordering to be preserved, otherwise a client could
be operating on stale data, send an update based on the stale data, and then later receive a delayed notify message
to update it's stale data, and it would not see the same total order as other clients.
> Now do you know why Richard is tearing his hair out for a
> working client? ;-)
Now do you know why I want to make locking as fine-grained
as possible and why I go to such great length with all this
XMIN and "select for update" business ? ;-)
Because I want to give you guys this benefit.
> I have toyed with the idea of having a per-client set of updateable
> views, on top of the 'business' views, thus enforcing 1:1 correspondence
> with GUI elements.
Well, in that scenario you'd have to make all the "business
views" be updatable/insertable. Or else you'd have to tell
your "dumb" business objects where to dump which data to.
And if the views are updatable and written to you'll have to
invent some formalism for the xmin handling as you may end
up with xmin values for several underlying tables in one
view. (Of course, I had to solve that, too.)
[Prev in Thread] | Current Thread | [Next in Thread] |