| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* 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.
|
|
Setting the new Mnesia parameter 'dump_disc_copies_at_startup' to
'false' will completely disable the DCD dumping while tables are being
loaded. If it is set to 'true' (the default), the same test will now
be performed as for normal dumps, i.e., using the 'dc_dump_limit'
parameter. Previously, the test performed at load time was different
from the one used at runtime, and caused a lot of unnecessary dumping
which slowed down the startup.
|
|
|
|
For performance reasons the file data is not synced to disk in mnesia,
data loss can happen between each dump.
mnesia:dump_log() can be used explicitly to ensure data is written to disk.
But that can take a long time, so mnesia:sync_log() which just
sync the log have been added.
|
|
Conflicts:
erts/etc/win32/Install.c
|
|
Mnesia_monitor detect mnesia down using a remote process link
and net_kernel nodeup to detect that a node are reacable again.
If there is a short node communication problem.
The node-down and node-up events can happen before the
remotely linked process generates an 'EXIT'.
When node-down and node-up events are recevied they are
stored and later checked if the node came up just before
mnesia flagged the node as down.
|
|
Bad timing could lead to hanging transactions after a mnesia down from a
node with sticky locks.
Excellent bug report from janchochol
Situation:
* node A and B have copies of table T
* node A ows sticky of table T
* node A goes down (e.g. crash)
* node B tries to perform transactional operation on table T
(e.g. mnesia:select)
In this situation there is possibility that first (and maybe other)
transaction on node B will hang indefinitely.
This is caused by race condition, when transaction process send lock
request operation to node A and waits for reply. When node A is down
it will never send reply, so process on node B will be stuck
forever.
Reason is that message sent to mnesia_locker gen_server from
mnesia_locker:mnesia_down can be received after mnesia_locker gen_server
already replies to transaction processes with {switch, N, Req} and
node N is down.
Monitoring remote process when sending request to other node should
be safe solution.
|
|
|
|
|
|
create_table
|
|
Aviods failing/wobbling testcase. Mnesia mishandled supervisors.
|
|
|
|
And remove old protocol version hacks
|
|
Resolve name clash with auto-imported BIF error/2.
|
|
A process that calls mnesia:subscribe(activity) will receive the message:
{mnesia_activity_event, ActivityID, complete}
when any activity that caused a change to a database has finished
committing its changes. This allows a subscriber to collect messages
already available through the mnesia:subscribe({table, ...}) system
to group them as completed transactions.
|
|
invoking mnesia:sync_transaction/[1,2]. Thanks Igor Ribeiro
Sucupira.
|
|
* is/mnesia-send-compressed:
Add option to compress data when copying tables between Mnesia nodes
OTP-8406 Igor Ribeiro Sucupira added the option to compress data when
copying tables between Mnesia nodes.
|
|
Optionally using data compression for copying Mnesia tables allows
the system to be tuned to eliminate network bottlenecks from
deployments where enough CPU is available to use zlib.
With this patch, running erl -mnesia send_compressed <level>
will enable compression for sending tables between nodes. The
compression level can be any integer in [0, 9], with 0 (the
default) meaning no compression (exactly the previous behaviour)
and 9 being the highest compression level.
To set any non-zero compression level at the sender, both nodes
must have the updated Mnesia modules (the receiver will work
according to the sender's configuration).
|
|
|
