DB Transactions and UI

[Mariano Montone]

Well, I have to say that Magma completely solves my problems.

I have this seaside code. It calls the user editor. The transaction is kept
among several requests. There's no transaction contention since locks are
not used and optimistic concurrency control is used instead. You can add and
remove groups to the user. If the user cancels, the transaction is aborted
and changes are rolled back (automatic undo :)). If the user accepts, then
the transaction commits and changes to the user are made effective. If
there's a commit error, then the application can handle it. It displays a
dialog informing the user of the error and then lets him edit again with a
fresh copy.

Sorry if this looks silly to you, but I don't know how to implement this
kind of thing in an ORM. I'm the author of a PHP Web/ORM framework but
achieving all these things is unfortunately not possible AFAIK.

There's at least one bug in the code. I don't know how to catch the user
intention of leaving the component by clicking on another link. If that
happens, then the transaction is not aborted nor commited. Leaving the user
in an unconsistent state and with a transactionLevelNumber = 1. What's more,
later editions will not work because of this (the commit will be ignored as
the transactionLevelNumber > 1).

This is the code (note that I'm not a Seaside expert nor a Magma expert):
editObject
    | session |
    session := self session magmaSession.
    session begin.
    [(body
            call: (APUserEditor on: self model))
        ifTrue: [session commit]
        ifFalse: [session abort].
    self viewObject]
        on: MagmaCommitError
        do: [:e |
            session abort.
            self inform: 'The user has been modified by another user. Edit
the user again, please'.
            self editObject]


Mariano

2007/6/29, Mariano Montone <marianomontone at gmail.com>:
>
> After having looked at the code, I see that an MagmaCommitConflict
> exception is raised and an apportunity for the application to decide what to
> do is given. That is exactly what I wanted. I didn't expect it to be
> implemented like that (I'm used to some RDBMS worlds where this kind of
> interaction with the DB is not possible, AFAIK).
>
> This looks very promising!!
>
> I'll be back after doing some tests.
>
> Thanks, Mariano
>
> 2007/6/29, Mariano Montone <marianomontone at gmail.com >:
> >
> > Chris, thanks for answering.  Some comments:
> >
> > 2007/6/28, Chris Muller <asqueaker at gmail.com>:
> > >
> > >  Hi Mariano, I have a couple of brief comments.
> > >
> > > The longer the transaction, the greater chance for for a commit
> > > conflict.  So how should a database handle this?
> >
> >
> > I expect the application to decide what to do. Maybe the DB could raise
> > a CommitConflict exception and maybe provide some restarts (ala Common Lisp
> > condition system) for the application to decide how to go on.
> >
> > I can't speak for others, but Magma doesn't silently restart any
> > > transactions, ever.  That example sounds like mismanagement of a
> > > dirty-read situation.
> >
> >
> > I'm interested in this one. How does the application gets notified of a
> > transaction need to restart? I think my problems could be solved depending
> > on this.
> >
> > Thanks, Mariano
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/magma/attachments/20070630/f423ff73/attachment.htm