Re: [Gnumed-devel] middleware upgrade

[Syan Tan]

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.)