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

[sjtan]

On Tue, 2003-02-25 at 18:13, Horst Herb wrote:
> 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
 is 'select for update' a new sql feature to distinguish a read only 
transaction,
from a read-write transaction? 
How does it work?