[Fwd: rdbms-1.0 user contribution]

[Ulf Wiger]

Hakan Mattsson wrote:
> 
> On Thu, 14 Jan 1999, Ulf Wiger wrote:
> 
> Uffe> BTW, I would like to be able to specify commit() and rollback() hooks in
> Uffe> the access module as well. I can imagine that such hooks would be
> Uffe> dangerous, but it would allow me to write safe triggers inside the
> Uffe> transaction. Currently, I have to wait until after commit/rollback and
> Uffe> do a post_update trigger - not atomic.
> 
> I have thought about introducing some kind of trigger to be executed
> at the end of transactions. But it is not so straightforward to do.
> 
> The first issue to think about is for what purpose what you want to
> use a trigger.

I was too embarassed to tell. ;)


> For the purpose of implementing integrity constraints it would be
> useful to a have a verfication trigger which should be run in the same
> context as the transaction, i.e. in the same process with full access
> to the transaction store. The transaction store access could either be
> indirect like lists:foldl/2 or explicit like ets:first/1 and
> ets:next/2. If the verification trigger is allowed to update the
> transaction store, the iteration order must not be affected by the
> updates. Such updates would of course be protected by the enclosing
> transaction as if they were performed in the transaction fun.  Like
> the current mnesia_access callback interface, a verification trigger
> mechanism would not be able to verify integrity constraints for
> updates performed via the mnesia:dirty_*-functions. The verification
> trigger could either be run for all transactions regardless of their
> nesting level or only for the outermost transaction.

The verification triggers seem to work just fine.

> 
> But since you mentioned that you wanted a rollback hook, I assume that
> its not only integrity constraints you are interested in. What whould you
> use a rollback hook for? debugging? supervision? health diagnostics?

The first use was this (I'm not saying it's a great idea):

I allow the definition of read() write() and delete() hooks, which means
that you can use mnesia:read(), write() and delete() on objects which do
not correspond to mnesia tables - instead, the corresponding hook
function is called instead. Obviously, these functions would have
side-effects, so it's important to know whether the transaction succeeds
or fails. For this purpose, I have written the functions
register:commit_action/1 and register_rollback_action/1, which are
called after commit or rollback.

Naturally, the hook functions must be prepared to be called several
times during one transaction, since the transaction may be restarted.


I also had in mind to provide different kinds of index (e.g. index on
derived or compound attributes.)

/Uffe
-- 
Ulf Wiger, Chief Designer AXD 301     <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuvägen 9, Älvsjö                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44