Как отключить устаревшее приложение от использования источников данных XA? - PullRequest
0 голосов
/ 23 мая 2018

У меня есть это устаревшее приложение, которое часто не может импортировать данные, возможно, из-за того, что некоторые транзакции охватывают слишком много SQL-операторов.Эти длинные транзакции действительно не нужны, поэтому я пытаюсь избавиться от них и просто использую обычный поиск и фиксации.Я не очень знаком с источниками данных XA и не очень понимаю, что контролирует, если используется XA или не XA.Я нашел места в коде, который выбирает между XA и не XA, но после установки этого всегда использовать не XA, я все еще получаю ошибки.Я также снял флажок «Поддержка протокола двухфазной фиксации» в «Фабриках соединений с очередями» на моем сервере, также безуспешно.На моем сервере есть источники данных, зарегистрированные как для XA, так и для не XA.Буду признателен за любую помощь в том, как и где отключить использование источников данных XA.

LocalTransact E   J2CA0030E: Method enlist caught com.ibm.ws.Transaction.IllegalResourceIn2PCTransactionException: Illegal attempt to enlist multiple 1PC XAResources
at com.ibm.ws.tx.jta.RegisteredResources.enlistResource(RegisteredResources.java:871)
at com.ibm.ws.tx.jta.TransactionImpl.enlistResource(TransactionImpl.java:1835)
at com.ibm.tx.jta.embeddable.impl.EmbeddableTranManagerSet.enlistOnePhase(EmbeddableTranManagerSet.java:202)
at com.ibm.ejs.j2c.LocalTransactionWrapper.enlist(LocalTransactionWrapper.java:624)
at com.ibm.ejs.j2c.ConnectionManager.lazyEnlist(ConnectionManager.java:2697)
at com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.lazyEnlist(WSRdbManagedConnectionImpl.java:2605)
at com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.beginTransactionIfNecessary(WSJdbcConnection.java:743)
at com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.prepareStatement(WSJdbcConnection.java:2792)
at com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.prepareStatement(WSJdbcConnection.java:2745)

Ответы [ 2 ]

0 голосов
/ 23 мая 2018

Прежде чем вносить изменения, которые вы не понимаете, вам лучше посоветовать оценить, может ли простое исправление или исключение (неуказанных) ошибок быть менее рискованным и менее трудоемким, чем переход от поведения XA к поведению не-XA.

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

Вы должны отредактировать свой вопрос, чтобы указать точные ошибки (например, sqlcodes или sqlstates), которые приложение получает в ответ на какие действия SQL.Иногда простые изменения конфигурации с низким риском могут устранить эти ошибки.

0 голосов
/ 23 мая 2018

Прежде чем ответить на это, я хочу отметить, что изменение логики транзакций без полного понимания того, что вы делаете, может поставить ваше приложение под угрозу проблем с целостностью данных, поэтому будьте осторожны.Если вы посмотрите на ту часть стека, которая соответствует тому, что вы разместили, она должна показать, какой код приложения использует объект java.sql.Connection.Следуйте коду, чтобы указать, где он получает соединение из источника данных, и укажите имя JNDI источника данных, который он использует.Переключите код, чтобы вместо него использовать имя JNDI для ConnectionPoolDataSource (не XA), а не XADataSource.После этого вы можете увидеть ошибки при включении нескольких однофазных ресурсов в транзакцию.Если это так, ваше приложение полагалось на двухфазную фиксацию, которая возможна только в XA, и вам нужно будет полностью реорганизовать ее (если вообще возможно), чтобы избежать использования двухфазной фиксации.С другой стороны, если было действительно намерение не включать этот источник данных в транзакции JTA, то вы можете пометить его как транзакция = ложь (при использовании Liberty) или nonTransactionalDataSource = true (традиционная WAS), в этом случае он будет избегать зачисления вТранзакции JTA и, следовательно, не будут участвовать в качестве двухфазного (XA) ресурса.

...