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

[Ian Haywood]

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 
too?

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:
                break
        elif error == concurrency:
                if showConcurrencyErrorBox () == tryagain:
                        result, error = patient.someMethod ()
                else:
                        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.

Ian

pgpRTXQlqN9zc.pgp
Description: PGP signature