[ https://forge.continuent.org/jira/browse/SEQUOIA-962?page=comments#action_14013 ]
Marc Herbert commented on SEQUOIA-962: -------------------------------------- First post: <http://thread.gmane.org/gmane.comp.db.sequoia.general/5344> > Reaction to "Duplicate Keys" error > ---------------------------------- > > Key: SEQUOIA-962 > URL: https://forge.continuent.org/jira/browse/SEQUOIA-962 > Project: Sequoia > Type: Bug > Components: Core > Versions: Sequoia 2.10.8 > Environment: Affects all OS, all database backends, and all hardware. > Tested on: linux, mysql/hsqldb and intel pentium. > Reporter: Paco Belloso > > > (submitted to gmane.comp.db.sequoia.general as "A question: duplicate keys") > I have configured a single controller with two MySQL backends on RAIDb-1 > configuration (no > controller replication by now) and then I've 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. This probably leads us to take care of a lot of different > sqlcode errors from diferent vendors.... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://forge.continuent.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira _______________________________________________ Sequoia mailing list Sequoia@lists.forge.continuent.org https://forge.continuent.org/mailman/listinfo/sequoia
