gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Data packs


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Data packs
Date: Sun, 25 Sep 2011 21:37:04 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Sep 25, 2011 at 11:55:36AM -0700, Jim Busser wrote:

> >> Presumably, it is a good thing that the Cancel button in
> >> the data pack picker dialog is included in what is blocked?
> > 
> > I don't think that's a good thing. I don't know how to
> > change it though.
> 
> When a data pack is in the midst of running, there could be side effects to 
> interrupting it.

While that's a valid concern it should not be a problem -
that's why we expect them to be wrapped in a transaction ...

> Supposing it would be interrupted by either a Cancel
> button (if such a button could be accessible) or by a Ctrl-
> key, what then?

Unless the code explicitely handles that case the connection
object will simply go out of scope. That will make it
inaccessible. Eventually it will be garbage collected at
which point the connection is closed which will make it roll
back.

> Ideally, data packs will all be written so that each
> module or section contained therein, in the case of
> interruption, will not leave the database in some incoherent
> state. I imagine that, to achieve this, each self-contained
> "subpack" should be wrapped in its own transaction.

Exactly.

> What I don't know is whether -- in the case of
> interruptions invoked from outside the script -- the
> transaction will remain "open" such that new activity in
> GNUmed will be lost on account of delayed failure of a
> commit.

:-)  No.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

[Prev in Thread] Current Thread [Next in Thread]