| 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.
|
|
|
|
* gorillainduction/improve_mnesia_locker_complexity:
Optimize tid lock table
OTP-11981
|
|
By making the ets table mnesia_tid_locks an ordered set instead of a
bag, the time for inserting locks for a transaction with large number
of locks is reduced significantly.
|
|
Be sure to gather release_tid msgs even though we have a mnesia_down
in the queue.
|
|
|
|
|
|
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.
|
|
|
|
If a transaction releases a write, it can be deleted directly since no read locks
or other write locks can be present
|
|
|
|
5% faster on tpcb
|
|
Switch to ordered_set so match_object matches partially bound keys,
more efficient.
|
|
Read from where_to_read otherwise bad data may read during
move_table, where where_to_write is updated before where_to_read
and the table is available.
|
|
wread on locks stuck at non-local node could return unexpected value.
Thanks to Magnus Henoch who posted a nice testcase showing the bug.
|
|
|
|
|
|
|
|
|
|
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
|
|
Resolve name clash with auto-imported BIF error/2.
|
|
|
