[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.