[Top][All Lists]

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

Re: [Gnumed-devel] concurrency error detection in business objects

From: Ian Haywood
Subject: Re: [Gnumed-devel] concurrency error detection in business objects
Date: Thu, 4 Nov 2004 23:24:36 -0500
User-agent: Mutt/1.3.28i

On Thu, Nov 04, 2004 at 10:50:49PM +0100, Karsten Hilbert wrote:
> Hi all,
>    detect and report. We use the fact that every table has a
>    column XMIN that represents the ID of the transaction that
>    last changed that row. Now, on the very first fetch we get
>    the XMIN value. Later on, when we try to lock the row for
>    update we use that initial XMIN value in the where clause
>    to select the row to be locked. If another process changed
This is a clever approach.
> Comments please. I should like to learn of any fallacies now
> rather than when real data is at stake.

I can't see any problems with this approach, I note it has been nicely
abstracted in the business layer, can we do this in the GUI calling code 

My fear is that every time we call a business object to commit data, 
we end up doing this:

while 1:
        result, error = patient.someMethod ()
        if error == ok:
        elif error == concurrency:
                if showConcurrencyErrorBox () == tryagain:
                        result, error = patient.someMethod ()
                        return 1
        elif error == .....
                showOtherError ()
                return 1
and so on.

As I have said, my first suggestion is to have an exception handler at
the top of the stack, an alternative is for the business layer to use
the dispatcher to report errors, passing a callable for repeating
the action.


Attachment: pgpRTXQlqN9zc.pgp
Description: PGP signature

reply via email to

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