| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Continuations returned from mnesia_ext backends were originally wrapped with
the backend module, but that was a remnant of the earliest implementation,
and is not actually needed, since Mnesia already knows what the table
storage type is when it applies the continuation. When mnesia_ext was ported
to OTP 19, the wrapper got changed to use the table type alias instead of
the module, which triggered an error in the mnesia_eleveldb backend. This
patch removes the wrapping completely.
|
|
|
|
Should maybe be moved to mnesia.erl and inlined??
Or is it used elsewhere?
|
|
* maint:
Fix a few dialyzer warnings
|
|
|
|
In most cases, we don't have to seed the random number generator,
as the rand:uniform/1 takes care about that itself.
|
|
|
|
The docs express that exit({aborted, Reason}) are called when
an error occur.
|
|
* dgud/mnesia/try-catch:
mnesia: Replace catch with try-catch
|
|
Avoids building stacktraces where it is not needed and do
not mask errors, i.e. only catch the relevant classes in each try.
|
|
|
|
|
|
|
|
|
|
Add stacktrace of mnesia processes.
|
|
|
|
Mainly to correctly clear dets tables. It may also be faster to use
the dedicated functions.
|
|
This commit is a preparation for introducing location information
(filename/line number) in stacktraces in exceptions. Currently
a stack trace looks like:
[{Mod1,Function1,Arity1},
.
.
.
{ModN,FunctionN,ArityN}]
Add a forth element to each tuple that can be used indication
the filename and line number of the source file:
[{Mod1,Function1,Arity1,Location1},
.
.
.
{ModN,FunctionN,ArityN,LocationN}]
In this commit, the fourth element will just be an empty list,
and we will change all code that look at or manipulate stacktraces.
|
|
Since the table loader also sets (table) write locks, a special
lock type, 'load', was needed. Unfortunately, this affects mnesia
activity callbacks that redefine the lock operation.
|
|
|
|
With help from Kostis
|
|
* uw/mnesia-overload:
Enable continuous monitoring of mnesia overload status
|
|
Mnesia currently issues an event whenever it detects an overload
condition. It recognizes two different types of overload:
- whenever the message queue of mnesia_tm process grows large
- when a log dump interval triggers before the previous dump is done
These events could be used to trigger a load regulation mechanism
to reduce the load until the condition seizes. The missing piece
is that there is no facility to ask mnesia whether the overload
condition still exists.
This patch implements a couple of functions in mnesia_lib that
can be used to sample the overload status. It has been tested
in a load regulator component being developed by Erlang Solutions.
No mnesia test suites have been run, since they are not available.
No documentation has been updated. The functions in mnesia_lib
are at any rate undocumented (as are all other functions in that
module). A decision would have to be made about whether to provide
a documented API on top of these functions.
The internal state record of mnesia_recover has been modified.
For this reason, a code change hook has been provided.
|
|
|
