[erlang-questions] Mnesia transactions and error handling good practices

[Alexander Lamb]

Ok, so on the one hand, the Erlang principles (and nested  
transactions) encourage you to divide your code in small functions.
On the other hand, performance issues might be a problem with nested  
transactions.

Now, there are 3 ways of handling this:

1) use nested transactions, at least for small computations, and  
ignore performance issues (if possible)
2) write larger functions which cumulate the functionalities normally  
split among several functions
3) write "no transaction" functions

Before I understood the concept of nested transactions, I did a mix of  
2 and 3. 3 means I write functions which imply they are going to be  
called from within a transaction. This works actually rather well,  
except you end up for several functions by writing to versions of  
each: one with a transaction and one without a transaction.
Solution 2 is not very good because it goes against the principle of  
atomicity in the code. I don't want code doing the same kind of task  
duplicated in several functions. Obviously, in the example I gave, it  
may not be very important, but in some cases it ended up with  
functions 40 lines long.

So I guess I will stick to solution 1 for small transactions and rely  
on a "bad match" exception for error handling, which seems a rather  
good compromise. Indeed, systematically testing for {aborted, Reason}  
even for transaction which should just not fail seems cumbersome in  
the code.

Thanks for the inputs,

Alex

Le 11 juin 08 à 18:35, Ulf Wiger (TN/EAB) a écrit :

> Hynek Vychodil skrev:
>> On Wed, Jun 11, 2008 at 4:38 PM, Daniel Luna <luna@REDACTED
>> <mailto:luna@REDACTED>> wrote:
>>
>>    On Wed, 11 Jun 2008, Andreas Hillqvist wrote:
>>> By the way, what is the cost of nested transaction in mnesia?
>>> Would it be "better practice" to keep this archive and set operation
>>> within only on transaction?
>>
>>    The cost of a nested transaction is proportional to the size of  
>> both of
>>    the transactions.
> ...
>> Just check, It means that if outer transaction is loose coupled to  
>> inner
>> (not make intensive data load from inner to outer), there is no  
>> problem
>> with transaction?
>
> No, all the data from the outer transaction is copied into the inner
> transaction, and all the committed data from the inner transaction
> is copied back into the outer.
>
> BR,
> Ulf W
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>