modeling-users

[Modeling-users] How are transaction failures handled?

[Federico H. <fh...@vi...>]

The Modeling manual explains pretty well how the validation mechanisms
work. There is no mention, though, about what happens when a transaction
fails because the dbms rejects it, nor of how transaction boundaries are
defined.

Or did I miss it?

	Fede

[Modeling-users] Re: How are transaction failures handled?

[Sebastien B. <sbi...@us...>]

Federico Heinz <fh...@vi...> wrote:
> The Modeling manual explains pretty well how the validation mechanisms
> work. There is no mention, though, about what happens when a transaction
> fails because the dbms rejects it, nor of how transaction boundaries are
> defined.
>=20
> Or did I miss it?

I did not check but you're probably right that this is not described in
the manual.

EditingContexts hold the transaction. That is to say, they work with the
underlying classes to control the underlying RDBMS transactions. ECs
handles:

- transactions at the object-level: A transaction at this level starts
  when the EC is created, or after a saveChanges(). All changes to the
  objects held by an EC are guaranteed to be saved as a whole, or not at
  all.=20

- Let's have a look at how saveChanges() works:

  1. it checks consistency at the object level --in particular, the differe=
nt
     validation mechanisms are triggered here. If anything goes wrong,
     it stops here: no transaction to the underlying db is opened.

  2. It then opens a transaction in the db, and sends the necessary SQL
     statements (INSERT/UPDATE/DELETE) in this transaction. If any error
     occurres when these sql statements are executed, the whole
     transaction is rolled back.

  3. It commits the transaction. Here again, if an error occurs at the
     DB-level, the transaction is rolled back.

(I supposed here that we are talking about EC that are not nested;
 nested ECs write the changes in their parent EC, not in the db)

In any case, if an error occurs, nothing is committed in the db.
Moreover, no changes are applied to the EC itself: e.g. the objects
marked as inserted remain the same before and after, etc. This gives you
the opportunity to correct the error (a validation error for example),
then to retry the saveChanges().

  Does this answer your question?

-- S=E9bastien.

Re: [Modeling-users] Re: How are transaction failures handled?

[Federico H. <fh...@vi...>]

Sebastien,

Thanks for the prompt answer! Indeed, this answers my question, but of
course it prompts another :-)

On Thu, 2003-09-25 at 09:46, Sebastien Bigaret wrote:
>   2. It then opens a transaction in the db, and sends the necessary SQL
>      statements (INSERT/UPDATE/DELETE) in this transaction. If any error
>      occurres when these sql statements are executed, the whole
>      transaction is rolled back.
>   3. It commits the transaction. Here again, if an error occurs at the
>      DB-level, the transaction is rolled back.

I assume that it also raises an exception at this point. Which exception
is this, and what information does it contain? (a pointer to the
relevant code is enough if you don't feel like writing a long answer).

	Fede

Re: [Modeling-users] Re: How are transaction failures handled?

[Sebastien B. <sbi...@us...>]

Federico Heinz <fh...@vi...> wrote:
> Thanks for the prompt answer! Indeed, this answers my question, but of
> course it prompts another :-)
>=20
> On Thu, 2003-09-25 at 09:46, Sebastien Bigaret wrote:
> >   2. It then opens a transaction in the db, and sends the necessary SQL
> >      statements (INSERT/UPDATE/DELETE) in this transaction. If any error
> >      occurres when these sql statements are executed, the whole
> >      transaction is rolled back.
> >   3. It commits the transaction. Here again, if an error occurs at the
> >      DB-level, the transaction is rolled back.
>=20
> I assume that it also raises an exception at this point. Which exception
> is this, and what information does it contain? (a pointer to the
> relevant code is enough if you don't feel like writing a long answer).

Two different exceptions can be raised

- ValidationException, which you already know,

- GeneralAdaptorException (raised by AdaptorChannel)

- and <embarrassed> hmm, well,... RuntimeError... </embarrassed>

  The relevant code is in ObjectStoreCoordinator's method
  saveChangesInEditingContext(). I *know* the exceptions should be
  better handled --I can still remember when I put the RuntimeError, I
  was finalizing the whole code underneath saveChanges() and didn't want
  to spend some time thinking of exceptions... Then it remained as is.

I'm also quite sure, although I did not check, that
GeneralAdaptorException is swallowed and mutated into a RuntimeError.

  The good news is that I never encountered such errors in any of the
  projects that are still alive. However, if in your environment you
  have, for example, a network that may cause db-connections to be
  randomly dropped, or specialized triggers/validation mechanisms that
  are only coded on the SQL side, then you'll probably need something
  better than a RuntimeError.

This is on the TODO list, obviously. And I'm open to any suggestions to
define the exceptions hierarchy.

-- S=E9bastien.