Health!
We are evaluating your wonderful system for production purposes in order to
replace some super-hyper-megadatabase I don't want to name ;-) ...
Well, I have configured a single controller with two MySQL backends on
RAIDb-1 configuration (no controller replication by now) and then I have
launched a simple application (that worked fine against a lonely mysql). This
program inserts (connection.autocommit = false) on the configured and empty
virtualdb, 126 INSERTS and after that inserts similar rows. The problem is when
the INSERT fails with a duplicate key, it aborts my transaction and the
folowing DELETE (of the same row) fails because the transaction is in aborted
state. Is there any configuration parameter to avoid this?. Am I doing
something incorrect?.
I've found (on sequoia-2.10.6 sources) that the code that fails is:
VirtualDatabase.statementExecuteUpdate()
catch (SQLException e)
{
String msg = "Request '" + request.getId() + "' failed ("+ e.getMessage()
+ ")";
if (!request.isAutoCommit())
{
// If the request fails in a transaction, the transaction is likely
// to be rollbacked by the underlying database. Then we have to abort
// the transaction.
msg = Translate.get("loadbalancer.request.failed.and.abort",
new String[]{request.getSqlShortForm(getSqlShortFormLength()),
e.getMessage()});
try
{
if (requestManager.getTransactionMetaData(new
Long(request.getTransactionId())) != null)
abort(request.getTransactionId(), true, false);
^^^^^
I think the comment says it all: "If the request fails in a transaction, the
transaction is likely to be rollbacked". I'm sure its right for almost cases
but no this one (duplicate keys). I think we should check for specified errors
like DUPLICATE KEYS, fill the SQLCode with appropiate error number and to NOT
ABORT the transaction.
Is correct this reasoning?.
Thanks and sorry my english.
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
