Одновременное изменение не должно регистрироваться как ОШИБКА? - PullRequest
Новая
       104

Одновременное изменение не должно регистрироваться как ОШИБКА?

0 голосов
/ 28 мая 2020

У нас есть приложение, работающее на Wildfly 17. У меня есть сценарий, который иногда возникает, в котором два фоновых потока обращаются к одному и тому же объекту:

  • Поток A удаляет объект (навсегда причина)
  • Поток B работает с немного более старыми данными и пытается обновить объект

Когда поток B является более поздним из двух, он терпит неудачу из-за одновременной модификации. Это работает правильно. Он автоматически повторяется и обнаруживает, что больше ничего делать не нужно (поскольку объект был удален). Это предполагаемое поведение, когда эти два потока сталкиваются. Все в порядке!

Однако я обнаружил, что это регистрируется как ОШИБКА CMTTxInterceptor : 

2020-03-31 16:51:35,463 +0200 ERROR: as.ejb3.invocation - WFLYEJB0034: EJB Invocation failed on component ... for method ... throws ...: 
  javax.ejb.EJBTransactionRolledbackException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:203) [wildfly-ejb3-17.0.1.Final.jar:17.0.1.Final]
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:364) [wildfly-ejb3-17.0.1.Final.jar:17.0.1.Final]
    at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:144) [wildfly-ejb3-17.0.1.Final.jar:17.0.1.Final]
    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
...
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
    at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
Caused by: javax.persistence.OptimisticLockException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
    at org.hibernate.jpa.spi.AbstractEntityManagerImpl.wrapStaleStateException(AbstractEntityManagerImpl.java:1729) [hibernate-entitymanager.jar:5.0.12.Final]
... at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:185) [wildfly-ejb3-17.0.1.Final.jar:17.0.1.Final]
    ... 262 more
Caused by: org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
    at org.hibernate.jdbc.Expectations$BasicExpectation.checkBatched(Expectations.java:67) [hibernate-core.jar:5.0.12.Final]
    at org.hibernate.jdbc.Expectations$BasicExpectation.verifyOutcome(Expectations.java:54) [hibernate-core.jar:5.0.12.Final]
    at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:46) [hibernate-core.jar:5.0.12.Final]
    at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:3261) [hibernate-core.jar:5.0.12.Final]
...

Мне кажется, что это log неверен, в основном потому, что это не ОШИБКА. Параллельная модификация - это нормальное явление, этого и следовало ожидать, и это обрабатывается нашим приложением logi c. Этот журнал отвлечет моих коллег на горячей линии.

Согласны ли вы с тем, что ведение журнала неверно, или я что-то упустил?

Думаю, я отключу ведение журнала для «as.ejb3.invocation».

1 Ответ

0 голосов
/ 29 мая 2020

В вашем случае это исключение было сгенерировано, потому что Hibernate обнаружил, что объект, ранее полученный из базы данных, был изменен (удален) во время текущей транзакции. Итак, обновлять нечего.

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

...