Hi Guillaume,
The problem is that when the application using Sequoia starts a
transaction, sometimes, the connection is reused before the
transaction is closed and we also have the case when the begin is
executed on one transaction and the commit on another one. We often
have the following case:
[pid:523] : BEGIN; first query of the transaction;
[pid:523] : other queries which have nothing to do in this transaction
[pid:534] : second query of the transaction;
[pid:534] : COMMIT;
This seems to be a bug in the application, I don't see how we can fix
that. If the application wildly shares a connection between multiple
clients, we cannot do anything about it. The only thing that Sequoia
guarantees, is that 2 concurrent calls on the same connection will be
serialized (basically all APIs calls are synchronized in the driver).
I dug a lot into the code for a while but I didn't find any problem
yet. Well, in fact, while digging for my problem, I found something
weird in the load balancer code but it doesn't apply to my case
because I have only one backend for my tests:
- in RAIDb1_RR.executeRoundRobinRequest, sequoia chooses a backend
without looking for the transaction id and runs
executeRequestOnBackend on this particular backend;
All backends are supposed to run all transactions, so you don't care
which backend has to be picked up.
- then in RAIDb1 executeRequestOnBackend takes care of the transaction
id to choose the right connection and guarantee the consistency of the
transaction, which is not possible if it chooses the wrong backend.
Is this the wanted behaviour? Anyway, it's not the problem I have
currently because I enabled only one backend.
When you want to execute a request in a transaction, we always pick up
the connection that corresponds to that transaction on that backend.
Transactions are lazily started (on-demand) so that we don't have to
open connections on all backends for a read-only transaction. This is
just an optimization. But it is not possible for an autocommit request
to use a connection from a transaction.
Does anyone have an idea of what can happen in my case and how I can
see what is the problem? A solution is also very welcome :).
I am not sure to fully understand the problem but you can check the
request.log file (by enabling request logging in log4j.properties) to be
sure that what the controller receives is really what you expect.
Thanks for your feedback,
Emmanuel
--
Emmanuel Cecchet
Chief Scientific Officer, Continuent
Blog: http://emanux.blogspot.com/
Open source: http://www.continuent.org
Corporate: http://www.continuent.com
Skype: emmanuel_cecchet
Cell: +33 687 342 685
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
