On Nov 1, 2007, at 3:07 AM, Adriano dos Santos Fernandes wrote:

> Autonomous transaction is a procedure/trigger flag meaning that the
> routine runs in an independent transaction.
>
> When one explicitly calls an autonomous procedure or the engine
> calls an
> autonomous trigger, a new transaction with same TPB of the current
> transaction is created to execute the routine.
>
> If the routine terminates due to exception, this transaction is
> rolled back.
> Otherwise it's automatically committed.
>
> ================
>
> Usage:
>
> 1) Autonomous triggers may be used to log (in non-external tables)
> tentatives (that may have failled) to change/insert/delete records.
>
> 2) ON CONNECT trigger may call an autonomous procedure to log (in
> non-external tables) rejected access
> to connect to databases.
>
> ON CONNECT trigger already can throw exceptions and reject logons, but
> with the exception the transaction
> is rolled back and the log doesn't survive.
>
> 3) Notify events to other processes without lose the transaction
> context.
>
> A autonomous procedure may update the database and call POST_EVENT.
> Withing the COMMIT, the events will be delivered.
>
> ================
>
> Syntax:
>
> CREATE PROCEDURE <name> [ <input and output arguments> ]
> [ AUTONOMOUS TRANSACTION ]
> AS
> BEGIN
> ...
> END
>
> CREATE TRIGGER <name>
> [ ACTIVE ] [ POSITION <n> ] ... [ AUTONOMOUS TRANSACTION ]
> AS
> BEGIN
> ...
> END
>
> ================
>
> ODS storage:
>
> Use RDB$FLAGS of RDB$TRIGGERS and add a column RDB$FLAGS to RDB
> $PROCEDURES.
> Use same bit mask for both tables.
>
> Adriano

I'd like to point out a couple places that have similar facilities.

1. the javaee ejb spec has a "requires new" transaction attribute for
ejb methods. When you call an ejb method with this attribute any
current transaction is suspended and a new one is started before the
actual method is called. On return, the new tx is ended with a
commit or rollback as marked and the original transaction if any is
resumed.

2. It proves to be a bit difficult for java developers to remember to
call the correct methods in the right order with the correct
exception handling to get this behavior with a plain JTA transaction
manager. IBM is proposing a new TransactionManager method in which
you submit a work item to be executed in a new transaction context.
The work item is an object with basically a run method on it.
Calling the method with your work item results in the current tx (if
any) being suspended, a new tx started, the work item run method
called, and on return the new tx ended and the original tx (if any)
resumed.

Neither of these say anything about the visibility of the work done
in the new transaction, that's left up to the isolation settings on
the resource manager.

One possible lesson is that it might be harder than it seems to get
the tx endings lined up properly with the tx starts. Therefore
restricting this to something like method calls might possibly serve
to prevent a lot of complaints from users who can't quite get all the
exception cases handled in their code.

thanks
david jencks