com.ibm.db2.jcc.am.SqlTransactionRollbackException: ошибка SQL DB2: SQLCODE = -911, SQLSTATE = 40001, SQLERRMC = 68, DRIVER = 3.65.110 - PullRequest
0 голосов
/ 08 мая 2018

Знайте, что есть много вопросов об этом. Это вызвано тем, что строка данных обновляется другим потоком, а другой поток не может получить блокировку. Тем не менее, я пытаюсь спросить более подробно:

У меня есть следующий код:

// catch all for hibernate super exception
    public SystemErrorCode map(final org.hibernate.JDBCException dae) {
        log.info( "dae : " + dae );
        log.info( "dae error code : " + dae.getErrorCode( ) );
        log.info( "dae sql : " + dae.getSQL( ) );
        log.info( "dae sql exception : " + dae.getSQLException( ) );
        log.info( "dae sql state : " + dae.getSQLState( ) );
        log.info( "dae cause : " + dae.getCause( ) );
        log.info( "dae message : " + dae.getMessage( ) );
        return new SystemErrorCode( "DAO0005", SYSTEM_DAO );
    }

А вот и журнал:

dae : org.hibernate.exception.LockAcquisitionException: could not execute native bulk manipulation query
dae error code : -911
dae sql : update PHistory SET  currentStatus = :currentStatus , MODIFIEDDATETIME = CURRENT TIMESTAMP where pHistoryId = :pHistoryId 
dae sql exception : com.ibm.db2.jcc.am.SqlTransactionRollbackException: DB2 SQL Error: SQLCODE=-911, SQLSTATE=40001, SQLERRMC=68, DRIVER=3.65.110
dae sql state : 40001
dae cause : com.ibm.db2.jcc.am.SqlTransactionRollbackException: DB2 SQL Error: SQLCODE=-911, SQLSTATE=40001, SQLERRMC=68, DRIVER=3.65.110
dae message : could not execute native bulk manipulation query

Когда я проверяю код, на самом деле нет другого потока для обновления той же записи, потому что pHistory является основным и уникальным.

Тем не менее, я продолжаю использовать эту вещь в производстве, и я не могу имитировать ее в своем локальном или SIT или UAT. Я пытаюсь узнать, в каком потоке или откуда мой код, я на самом деле блокирую ту же строку, а затем вызываю эту ошибку.

1 Ответ

0 голосов
/ 10 апреля 2019

Я наконец нашел причину и сумел ее решить. На самом деле это вызвано огромным количеством записей таблицы PHistory, множеством связей с другими таблицами и меньшим количеством индексаций.

Я запустил db2expln для этого запроса и обнаружил, что добавление предложенного индекса улучшит производительность на 99%. После добавления индекса, мониторинга в течение нескольких месяцев и хороших новостей, которых больше нет, это исключение происходит в моей программе.

Итак, на самом деле это не вызвано тем, что другой поток обновляет ту же строку, я нахожу решение неверным способом. Пока я не проверю индекс. Таким образом, в будущем, если с вами случится какая-то похожая проблема, как насчет того, чтобы попробовать сделать индекс и посмотреть результат.

...