|
| From: | Syan Tan |
| Subject: | Re: [Gnumed-devel] middleware upgrade |
| Date: | Sat, 24 Dec 2005 09:41:24 +0800 |
I was wondering if xmin checking was necessary if you had fine grained commit intervals ; so commit at every update
when an item is changed or added in the gui view of the medical record, then reopen a transaction for the next commit. this would mean
a user who has a too-late update due to another user earlier updating the same item and committng, will be notified with a transaction
abort . the client response is to then refetch the missed update for the user trying to update late, and these values displayed to the
user for reconciliation ; the user can be given an option to revert to the new update values, reedit , or proceed with his update,
which is then issued in a new transaction , and then overwrites the other users changes. The other user would be notified accordingly.
other users receiving notification would update notified values locally , and perhaps there could be a message panel, telling users
what updates the other users have done ( just who, when, and what as the category of item updated in which record). checks could
be done so another line is placed in the message panel e.g. " *warning* Dr Bastard overwrote your recent 512 word social history changes of 12:02 pm today, at 12:12 pm today with 5 words ".
On Thu Dec 22 19:39 , Karsten Hilbert sent:
On Thu, Dec 22, 2005 at 08:26:29AM +0800, Syan Tan wrote:
> xmin piqued my interest again in distributed shared memory topic, and I went
> back and read about
> - 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.
GNUmed is then write-invalidate the way it's written now.
> 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 ,
Exactly, it is not. It uses several threads to listen for
out-of-framework events (such as from PostgreSQL or from
XML-RPC clients).
> as it has to spawn a blocking thread that listens for updates,
Except that the "blocking" thread does a neverending pull
loop. Which is functionally equivalent to blocking.
> Is postgres's notify command blocking for the server ( server blocks waiting
> for aknowledgement of notify from all clients) ?
No, it does not wait for other clients.
> It probably should be, because all
> active clients need
> to acknowledge receipt of a single notify
It doesn't even guarantuee that there will be a 1:1
correspondence between initiated and delivered notifies. It
can happen that a client receives only one notify for a
given type if they were initiated in quick succession and
the client did not pick up the first before the second was
initiated).
> 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
Yes, but we protect against that with the xmin code.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
_______________________________________________
Gnumed-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnumed-devel
| [Prev in Thread] | Current Thread | [Next in Thread] |