| Author |
Message |
|
| ulf.wiger at etxb.ericsso |
 Posted: Wed Jan 13, 1999 3:19 pm |
 |
|
|
Guest
|
Oops! forgot the Cc.
--
Ulf Wiger, Chief Designer AXD 301 <ulf.wiger_at_etxb.ericsson.se>
Ericsson Telecom AB tfn: +46 8 719 81 95
Varuv |
|
|
| Back to top |
|
| hakan at erix.ericsson.se |
| Posted: Thu Jan 14, 1999 9:08 am |
|
|
|
Guest
|
On Wed, 13 Jan 1999, Ulf Wiger wrote:
Uffe> > When it comes to nested schema transactions, you said
Uffe> > "..it is not well documented in mnesia how to perform a series of
Uffe> > schema operations within one schema transaction". This is true and
Uffe> > the simple reason for not documenting that is that nested schema
Uffe> > transactions is not a part of the public API. We do not want to
Uffe> > encourage our customers to use our internal functions.
Uffe>
Uffe> Well, there are customers and there are customers... 
Uffe>
Uffe> I don't agree with the policy that you should keep users away from a
Uffe> dangerous operation by making it impossible to do, or impossible to
Uffe> find. Provide a low-level interface and document clearly that you
Uffe> shouldn't use it unless you know what you're doing.
My intention is not to make the internal functions hard to use. But
writing documentation of these have had a rather low priority. The
main reason for not encouraging usage of internal functions is that
their behaviour may be changed without any notice. We put no effort in
making them backwards compatible. You have to be aware about that if
your code uses internal functions, it may be broken in the next
release.
Uffe> What if I want to create 10 tables or none at all? This shouldn't be an
Uffe> unusual situation. It requires being able to call all create_table/2
Uffe> functions within one transaction.
Yes.
It would be nice to be able to nest any combinations of schema
transactions and plain table access inside an enclosing atomic
transaction. Its not hard to do, but it simply has not been done
yet. The plan is to remove several of the current restrictions in
schema transactions in future releases.
/H |
|
|
| Back to top |
|
| ulf.wiger at etxb.ericsso |
| Posted: Thu Jan 14, 1999 9:42 am |
|
|
|
Guest
|
Hakan Mattsson wrote:
>
> My intention is not to make the internal functions hard to use. But
> writing documentation of these have had a rather low priority. The
> main reason for not encouraging usage of internal functions is that
> their behaviour may be changed without any notice. We put no effort in
> making them backwards compatible. You have to be aware about that if
> your code uses internal functions, it may be broken in the next
> release.
Indeed! It's happened to me a couple of times.
That's life on the bleeding edge. (:
I use the following undocumented mnesia functions in rdbms:
- I fetch the transaction data directly from the process dictionary
(could have used mnesia:get_activity_id(), but I didn't see it,
and it's also marked as "not for public use" btw)
I decided to do this since the dictionary generates read/write
activity inside the transaction; if it would use
mnesia:read/1 and mnesia:write/1, it would create a loop (they are
forwarded back again to the dictionary for verification.)
It would have been possible to work around it, but this felt like
the most elegant solution.
- mnesia_schema:schema_transaction/1 and
mnesia_schema:do_write_table_property/2
This could perhaps have been avoided if I'd realised that there
was a 'user_properties' option for create_table/2.
If I figure out a way to rewrite this cleanly to use only the official
API, I will of course do that.
BTW, I would like to be able to specify commit() and rollback() hooks in
the access module as well. I can imagine that such hooks would be
dangerous, but it would allow me to write safe triggers inside the
transaction. Currently, I have to wait until after commit/rollback and
do a post_update trigger - not atomic.
/Uffe
--
Ulf Wiger, Chief Designer AXD 301 <ulf.wiger_at_etxb.ericsson.se>
Ericsson Telecom AB tfn: +46 8 719 81 95
Varuv |
|
|
| Back to top |
|
| hakan at erix.ericsson.se |
| Posted: Thu Jan 14, 1999 12:41 pm |
|
|
|
Guest
|
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 |
|
|
| Back to top |
|
| ulf.wiger at etxb.ericsso |
| Posted: Thu Jan 14, 1999 1:03 pm |
|
|
|
Guest
|
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_at_etxb.ericsson.se>
Ericsson Telecom AB tfn: +46 8 719 81 95
Varuv |
|
|
| Back to top |
|
| hakan at erix.ericsson.se |
| Posted: Thu Jan 14, 1999 2:44 pm |
|
|
|
Guest
|
On Thu, 14 Jan 1999, Ulf Wiger wrote:
Uffe> > But since you mentioned that you wanted a rollback hook, I assume that
Uffe> > its not only integrity constraints you are interested in. What whould you
Uffe> > use a rollback hook for? debugging? supervision? health diagnostics?
Uffe>
Uffe> The first use was this (I'm not saying it's a great idea):
Uffe>
Uffe> I allow the definition of read() write() and delete() hooks, which means
Uffe> that you can use mnesia:read(), write() and delete() on objects which do
Uffe> not correspond to mnesia tables - instead, the corresponding hook
Uffe> function is called instead. Obviously, these functions would have
Uffe> side-effects, so it's important to know whether the transaction succeeds
Uffe> or fails. For this purpose, I have written the functions
Uffe> register:commit_action/1 and register_rollback_action/1, which are
Uffe> called after commit or rollback.
Uffe>
Uffe> Naturally, the hook functions must be prepared to be called several
Uffe> times during one transaction, since the transaction may be restarted.
In my first implementation of the mnesia_access callback interface, I
had the notion of virtual transactions. With hooks for start,
verification, commit and abort of activities. Sorry Uffe.
/H |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
