Commit 9a6ad2e6 authored by Julien Muchembled's avatar Julien Muchembled

Update BUGS

One entry should have been removed before v1.1
parent a5f2f604
......@@ -14,12 +14,12 @@ Although this should happen rarely enough not to affect performance, this can
be an issue if your application can't afford restarting the transaction,
e.g. because it interacted with external environment.
Master failure not recovered by clients
Client always raise in tpc_finish if a failure happen
After a master failure, clients are stuck in a bad state. In particular, caches
are not flushed, which could lead to data corruption if they reconnect a master.
This makes secondary masters mostly useless for the moment.
This is wrong because the failure may actually happen just after the transaction
is actually committed. Client should not raise if it can reconnect and note
that the transaction exist.
Storage failure or update may lead to POSException or break undoLog()
......@@ -148,7 +148,7 @@ RC - Review output of pylint (CODE)
This can happen if it gets disconnected from primary master while waiting
for AnswerFinishTransaction after primary received it and hence will
commit transaction independently from client presence. Client could
legitimaltely think transaction is not committed, and might decide to
legitimately think transaction is not committed, and might decide to
retry. To solve this, client can know if its TTID got successfuly
committed by looking at currently unused '(t)trans.ttid' column.
See neo.threaded.test.Test.testStorageFailureDuringTpcFinish
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment