Реализация поддержки вложенных транзакций с использованием JDBC 3.0 - PullRequest
1 голос
/ 06 февраля 2009

наше устаревшее приложение использует JDBC 3.0. он поддерживает транзакции, реализуя собственный менеджер транзакций, который способен возвращать одно и то же соединение JDBC для каждого потока. Проблема, которую я недавно обнаружил, заключается в том, что она не поддерживает вложенные транзакции: если транзакция запускается внутри другой транзакции, то каждый SQL-запрос, выполняемый в контексте внутренней транзакции, будет выполняться с использованием того же соединения с БД, а когда он будет зафиксирован или откат будет автоматически подтвержден или откатит все изменения, начиная с внешней транзакции.

Насколько я понимаю, я могу реализовать поддержку вложенной транзакции, используя точки сохранения JDBC 3.0: всякий раз, когда вложенная транзакция запускается, я могу установить новую точку сохранения для текущего соединения. После этого, если вложенная транзакция откатывается, я просто вернусь к этой точке сохранения. Если, с другой стороны, это будет зафиксировано, я просто ничего не буду делать. Только фиксация самой внешней транзакции сохранит изменения в БД.

Это правильно? Есть ли у этого подхода недостатки? Если да, каковы мои возможности?

Спасибо.

Ответы [ 3 ]

1 голос
/ 06 февраля 2009

В коде могут быть зависимости, которые ожидают, что принятие будет выполнено, а не отложено (например, если уровень изоляции установлен на TRANSACTION_READ_COMMITTED).

Рассмотрите возможность исправления вашего менеджера транзакций для выполнения вложенной транзакции в отдельном соединении.

ОБНОВЛЕНИЕ: похоже, что среда Spring использует SavePoints для предоставления вложенных транзакций. Я предполагаю, что они просто игнорируют проблему режима изоляции.

1 голос
/ 03 июня 2009

Вы можете попробовать поддержку вложенных транзакций в Atomikos TransactionsEssentials .

Однако вложенные транзакции в СУБД обычно ограничиваются следующим образом:

- либо ваши вложенные транзакции совместно используют одну и ту же транзакцию БД, что обеспечивает общий доступ к данным за счет степени детализации отката (вы полностью откатываете)

- или ваши вложенные транзакции сопоставляются (Atomikos) с различными базовыми транзакциями БД, за счет того, что вы не разрешаете общий доступ к данным для точек доступа

Это несоответствие связано с ACID-характером транзакций базы данных. В конце концов, все ваши обращения к СУБД обязательно должны произойти в такой транзакции базы данных.

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

Лучший Guy

1 голос
/ 06 февраля 2009

Транзакции немного сложны и не могут быть просмотрены на уровне JDBC, но лежат в основе самой базы данных. С этого момента я буду говорить об Oracle, поскольку у меня больше всего опыта. В Oracle, если вы запускаете транзакцию, вы можете выполнить откат к точкам сохранения внутри транзакции, но вы не можете зафиксировать, используя точки сохранения. Допустим, я начал транзакцию и у меня есть три точки сохранения, A, B и C. Я могу спокойно перейти вперед и откатиться к A, B или C, но как только вы подтвердите, вы начали новую транзакцию, а теперь A, B и C больше не действительны. Я надеюсь, что это хорошо поможет ответить на ваш вопрос.

...