Re: [PyPerSyst-Devel] concurrent users

[Donnal W. <don...@ya...>]

--- "Patrick K. O'Brien" <po...@or...> wrote:
> How this UpdateRevisionMismatch exception should be handled
> by the user interface is up to the client application.  In
> some cases the changes should simply be dropped.  In other
> cases, the user may have spent a lot of time typing in the
> changes and would lose a lot of work if you didn't give them
> the option to resolve any anomalies and create a new
> transaction.  A lot depends on the particular domain.  The
> issues are basically the same as with any multi-user database.
> I'm open to any suggestions if there are other mechanisms
> that would be useful to have support for in PyPerSyst.

> Did that help answer your questions?

Yes it did, thanks. I realized later, however, that my subject line
is somewhat misleading. The apps I hope to develop are *multi-user*
in a sense, but probably not truly *concurrent* users. If you will
indulge me, let me try to describe the situation.

The domain I have in mind is clinical, and multiple clinicians will
need to update the patient information. But for any given patient
at any given time, *only one* clinician will typically need to
update the information. It would work well for a clinician to be
able to check out a patient record, and until that record is
checked back in, other users could *see* the record but would not
be allowed to modify it. This is not an artificial scenario made up
to over simplify the problem. It is the typical situation. In the
case where two clinicians want to update information at the same
time, the second could simply be informed (before the fact) that
the record is checked out temporarily.

It might seem like Twisted would be a good solution here, since
there would be relatively few update conflicts, but IMHO it would
be better to inform a user that a given record is in use *before*
editing the data rather than during an attempted transaction.

PyPerSyst, if I understand correctly, keeps the entire database in
memory, but I don't see why there couldn't be multiple "documents"
in place of a single "root". Each document would have a "snapshot"
and possibly a "log file". Any valid user should be allowed to open
a snapshot for reading at any time. But if the user wants to check
out a document for updating, the application should first check to
see if there is a "log file" for that document. If so, it assumes
that another user is updating the document and leaves it alone. If
not, it creates a log file: (1) for logging transactions, and (2)
for letting other users know that they cannot have write access at
present. When the editing is finished, a new snapshot is saved and
the log file is deleted (letting another user know that it is safe
to open it in update mode).

Regards,

=====
Donnal Walter
Arkansas Children's Hospital