[ https://forge.continuent.org/jira/browse/SEQUOIA-962?page=comments#action_14015 ]
Paco Belloso commented on SEQUOIA-962: -------------------------------------- Marc: We are working for banking firms that have almost all its activities computerized. One of the many applications of the system (EF) has a batch program that runs along big files (we are talking of gigabytes) reading records and inserting into db, some of them can match a previous record with the same key (duplicate_keys error ....) in that case an UPDATE is done for the record. This procedure (INSERT->duplicate_key_error->UPDATE) is repeated in hundred of programs (batch and online). But what we demand / complaint is that in none database we work (db2, mysql, hsqldb) a duplicate_keys error forces a transaction abort. Am I wrong?. Sorry my english. And thanks. On thursday I go to holidays and where I go three is no internet (neither 3G;). Please pardonne moi. > 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
