Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
N
neoppod
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Levin Zimmermann
neoppod
Commits
9a6ad2e6
Commit
9a6ad2e6
authored
Jun 03, 2014
by
Julien Muchembled
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Update BUGS
One entry should have been removed before v1.1
parent
a5f2f604
Changes
2
Show whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
6 additions
and
6 deletions
+6
-6
BUGS
BUGS
+5
-5
TODO
TODO
+1
-1
No files found.
BUGS
View file @
9a6ad2e6
...
...
@@ -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 momen
t.
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 exis
t.
Storage failure or update may lead to POSException or break undoLog()
---------------------------------------------------------------------
...
...
TODO
View file @
9a6ad2e6
...
...
@@ -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
legitima
l
tely 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
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment