gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 3, Issue 29


From: Horst Herb
Subject: Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 3, Issue 29
Date: Tue, 25 Feb 2003 08:13:08 +0100
User-agent: KMail/1.5

On Mon, 24 Feb 2003 02:12 pm, sjtan wrote:
> You are assuming that a 2 tier system is always better than an N-tier
> system. I take Horst's point that a 2 tier system retains the power of
> SQL queries.

Yes, very difficult and very performance expensive to retain tthat power in a 
>2 tier system. However, this should not stop us from implementing a "pseudo 
3rd tier" *within* an application trying to cleanly separate "businesss 
logic" from user interface

> For instance, is it at each page viewing change? What if there are 2
> clinicians entering data and the scope of the transaction boundary is
> patient wide, so that one clinician finishes his entry and then is
> informed his update is aborted because MVCC detects that there is a
> read-write write-read or write-write conflict.

This *cannot* happen:
1.) clinical records are identified by person concerned, time, place and 
author. In your case, author is different = two different records
2.) in the rare case where two authors decide to alter an already existing 
non-time-sequential record, the data entry widget will of cause issue a 
"select for update" statement as soon as a change in content is detected 
(first character modified), which locks that particular row for update (but 
never for read - that's what MVCC is for).

Horst




reply via email to

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