[erlang-questions] How to break out from mnesia transaction?

attila.rajmund.nohl <>
Mon Feb 5 15:49:12 CET 2007


On Mon, 5 Feb 2007, Jani Launonen wrote:

>> Hello!
>>
>> I have to implement function a() which have to call function b().
>> Function a() is always called from a mnesia transaction, while
>> functionb() can't be called from a mnesia transaction. How can I
>> solve this
>> problem elegantly? My idea is start a process from a(), send a message
>> to the process, which in turn will call b() (it's now outside of the
>> transaction, right?) and when b() returns, the process sends
>> back a
>> message to a(). Is there a simpler way to solve the problem?
>
> Sending message from a transaction is a bad idea --- in fact any side-effect inside transaction is a bad idea --- if the transaction have to be restarted (which Mnesia does automatically if need arises). Then there would be several messages sent to the process calling the function b().

Actually function b() has side effects, that's why I need to call it and
I guess that's the reason why it returns an error code if it's called
from a transaction.

> I wonder if there's elegant solution to this, but perhaps restricting Mnesia transactions to only one (somewhere was such parameter) or giving some unique identifier outside of transaction containing the function a() which is sent with the message to process calling the b(). Then, if b receives the same identifier twice (or more times if Mnesia restarts the transaction several times) it discards such calls, but returns the previous answer. A bit hacky, I have to admit, but it's been some years that I had to study the subject during my thesis. I'm interested in hearing the "correct" solution from pros :)

I don't know the black magic involved, but the transaction which calls
a() is special: it's restarted exactly once and a() even knows if it's
the first run or the second, so I could send the message exactly once.

 				Bye,NAR
-- 
"Beware of bugs in the above code; I have only proved it correct, not
  tried it."



More information about the erlang-questions mailing list