[
https://forge.continuent.org/jira/browse/SEQUOIA-962?page=comments#action_14009
]
Emmanuel Cecchet commented on SEQUOIA-962:
------------------------------------------
Why do you try to DELETE the row, since it was not inserted (insert failed with
duplicate key)?
Why don't you just simply rollback the transaction?
Databases like PostgreSQL and others would rollback the transaction anyway and
would not allow your DELETE to go through.
It looks to me that your code should be like: try { begin;insert;commit } catch
(e) { rollback(); begin;delete;commit;} even though I don't really understand
the logic behind the delete thing.
> 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
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
