Closed SuperLeilia closed 2 years ago
Thank you @SuperLeilia! We will try to reproduce the setup and test to debug. One question: What type of CRDT are you using for the reads/writes, e.g. LWWRegister?
Hi @bieniusa , I used LWWRegister and with Python client.
To facilitate your debugging, I attached my test code @bieniusa
The Antidote Python client currently does not support session guarantees, so there is no happens-before relation between operations that are executed on the same thread. Does your analysis depend on session guarantees or is it still a consistency violation?
Session guarantees are supported in the Javascript client (see https://antidotedb.github.io/antidote_ts_client/#session-guarantees) and Java client (pass CommitInfo timestamp
to a transaction).
Thanks for your reply, @peterzeller ! Some comments/questions:
We followed https://github.com/AntidoteDB/antidote-python-client, as well as the official document, to deal with client-side logic (for txns). We couldn't find anywhere that python clients cannot work with causal consistency. Are we missing anything?
What do you mean by "no happens-before relation"? Our ops and txns are closed loop and they are definitely ordered by the program order, right? Additionally, based on the returned data, we can infer the write-read order among operations/txns (from possibly different clients) as well, right? If Antidote provides causal consistency, we shouldn't have seen the counterexample posted above.
For python client, what about causal consistency at the process level (e.g., one single thread per process)? There should not be any doubt that a process itself constitutes a session, right?
Are you suggesting that, to benefit from Antidote's causal consistency guarantee, we must currently use either Javascript or Java client?
Looking forward to your reply! Thanks!
@SuperLeilia I have added the option to the python client in this PR: https://github.com/AntidoteDB/antidote-python-client/pull/4
With this change you can set the minimum snapshot time in your code like this:
tx = clt.start_transaction(min_snapshot=clt.last_commit)
The last_commit
field is set whenever you have committed a transaction.
Our ops and txns are closed loop and they are definitely ordered by the program order, right?
Antidote does not use the implicit program order - you need to pass the commit timestamp from the previous operation to the next operation manually.
I don't remember exactly why we designed it like this, but I think it was something like this:
Would be cool if you could try with the min_snapshot
option.
@peterzeller Thanks for your reply! I noticed that the new commits (e.g. last_commit field) are on the branch 'session-guarantees-support'. We install Antidote client via "pip antidotedb" which we assume works with the master branch. How can we proceed with the testing?
It is on master now; I just merged the PR.
I have uploaded the current version to pip... you should be able to use the new version using pip now.
Annette Bieniusa @.***> escreveu no dia domingo, 30/01/2022 à(s) 12:23:
It is on master now; I just merged the PR.
— Reply to this email directly, view it on GitHub https://github.com/AntidoteDB/antidote/issues/458#issuecomment-1025132062, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACLFD4TDE5465ALKA3B5X5DUYUUSTANCNFSM5JEOXA4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
@preguica @bieniusa @peterzeller Thanks for fixing the python client issue!! The new version is running smoothly so far. I'll get back to you if any anomaly identified :D
Hi, we have found a bug while checking causal consistency of Antidote. We have printed operations to the database and return values from database into logs.
The configurations are listed below:
The log file is attached at the end of this post . Note that operation is in the type of operation_type(variable, value, client_id, transaction_id).
We have found that transaction 0 can reach transaction 39 by the order in each client and write-read relation. Aiso in transaction 39 we have found w(0,62) and in transaction 0 we have found r(0,62), so transaction 39 can reach transaction 0, which made it a cycle. Obviously it violates causal consistency.
Datalog files FYI: result.txt