[Fwd: rdbms-1.0 user contribution]

[Hakan Mattsson]

On Thu, 14 Jan 1999, Ulf Wiger wrote:

Uffe> I use the following undocumented mnesia functions in rdbms:
Uffe> 
Uffe> - I fetch the transaction data directly from the process dictionary
Uffe>   (could have used mnesia:get_activity_id(), but I didn't see it,
Uffe>    and it's also marked as "not for public use" btw)
Uffe>   I decided to do this since the dictionary generates read/write 
Uffe>   activity inside the transaction; if it would use 
Uffe>   mnesia:read/1 and mnesia:write/1, it would create a loop (they are
Uffe>   forwarded back again to the dictionary for verification.)
Uffe>   It would have been possible to work around it, but this felt like
Uffe>   the most elegant solution.
Uffe> 
Uffe> - mnesia_schema:schema_transaction/1 and
Uffe>   mnesia_schema:do_write_table_property/2
Uffe>   This could perhaps have been avoided if I'd realised that there
Uffe>   was a 'user_properties' option for create_table/2.
Uffe> 
Uffe> If I figure out a way to rewrite this cleanly to use only the official
Uffe> API, I will of course do that.
Uffe> 
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.

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.

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?

If the purpose instead is notification there already exists an fairly
reliable subscription mechanism in Mnesia that could be
used. Introducing a commit trigger (to be run in the coordinator
process) for the purpose of notification is not an especially good
idea, since it is almost impossible to safe guarantee delivery of
notifications if the transaction coordinator process dies during
commit. The participant processes on other nodes may decide to
fullfill the commit of the transaction even if the coordinator is
dead.  If this is the case, a commit trigger run in the coordinator
process would not be able to deliver its notifications. Mnesia's
subscription mechanism is designed to take care of this situation.
As long as there is an active replica of the updated table, the
notification will be delivered to its subscribers.

/Håkan