Пакетное обновление в драйвере Postgresql JDBC откатывается в автокоммит

Question

Пакетное обновление в драйвере Postgresql JDBC откатывается в автокоммит

1

Я делаю пакетные вставки с помощью драйвера postgres 9.3-1100-jdbc41 JDBC4.

Согласно спецификации JDBC, ее приложение может отключить автообновление и совершить или отменить транзакцию.

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

Согласно спецификации JDBC "Если одна из команд в пакетном обновлении не выполняется должным образом, этот метод генерирует исключение BatchUpdateException, а драйвер JDBC может или не может обрабатывать оставшиеся команды в пакете". Здесь он не говорит, что ранее выполненные команды будут отброшены назад.

Я понимаю, что неправильно? Если нет, то почему драйвер ведет себя таким образом, и если да, то каково правильное поведение в соответствии со спецификацией.

Mukesh Negi 07 апр. 2015, в 09:18

Источник

3

Если вы используете автоматическую фиксацию, все пакетные вставки все еще выполняются в одной транзакции, если я не ошибаюсь. Думайте об этом как об ином способе записи одной вставки, которая вставляет много строк ( insert into .. values (..),(..),(..),(..) )
a_horse_with_no_name 07 апр. 2015, в 06:42
0

Спасибо за ваш ответ. Но как насчет спецификации. Я думаю, что это просто, чтобы избежать обходов по сети для каждой вставки и применять транзакции должно быть в зависимости от приложения. На БД каждая вставка должна быть выполнена как единое целое. Как пользователь, я могу добавить несвязанные вставки в один пакет, чтобы избежать обратной передачи, которую не следует откатывать в случае сбоя какой-либо команды.
Mukesh Negi 07 апр. 2015, в 06:50
1

Что ж, спецификация гласит: « Может или не может продолжить процесс » - Postgres решает не продолжать.
a_horse_with_no_name 07 апр. 2015, в 06:59
0

спецификация говорит «может или не может продолжать обрабатывать дальнейшие команды». Я также нашел эту ссылку, но она слишком старая, postgresql.org/message-id/…
Mukesh Negi 07 апр. 2015, в 07:16
0

Так что же неясно про " может не продолжаться "?
a_horse_with_no_name 07 апр. 2015, в 07:24

Показать ещё 3 комментария

Теги:

java

postgresql

jdbc

1 ответ

Ещё вопросы

Если вы используете автоматическую фиксацию, все пакетные вставки все еще выполняются в одной транзакции, если я не ошибаюсь. Думайте об этом как об ином способе записи одной вставки, которая вставляет много строк ( insert into .. values (..),(..),(..),(..) )
Спасибо за ваш ответ. Но как насчет спецификации. Я думаю, что это просто, чтобы избежать обходов по сети для каждой вставки и применять транзакции должно быть в зависимости от приложения. На БД каждая вставка должна быть выполнена как единое целое. Как пользователь, я могу добавить несвязанные вставки в один пакет, чтобы избежать обратной передачи, которую не следует откатывать в случае сбоя какой-либо команды.
Что ж, спецификация гласит: « Может или не может продолжить процесс » - Postgres решает не продолжать.
спецификация говорит «может или не может продолжать обрабатывать дальнейшие команды». Я также нашел эту ссылку, но она слишком старая, postgresql.org/message-id/…
Так что же неясно про " может не продолжаться "?

Craig Ringer · Answer 1 · 2015-04-07T05-09-00.000Z

1

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

PgJDBC выполняет партию в транзакции, поэтому, если какая-либо часть пакета терпит неудачу, она будет прервана.

Если вы считаете, что это поведение неверно, первое, что вам нужно сделать, это написать тестовый пример, демонстрирующий, что другие драйверы ведут себя по-разному к PgJDBC и отправляют его в трекер PgJDBC. У нас нет времени для исследования поведения других драйверов, поэтому вам нужно написать тестовый пример и запустить его в некоторых других популярных базах данных (MS SQL Server, Oracle, DB2, MySQL и т.д.) Или организовать его запуск другими. Если вы обнаружите, что поведение PgJDBC отличается от того, как другие драйверы обрабатывают партии, тогда стоит подумать о добавлении опции для изменения поведения (и в конечном итоге сделать это по умолчанию).

Craig Ringer 07 апр. 2015, в 05:09

1

Я не думаю, что вы можете изменить поведение драйвера - в конце концов, сам Postgres не позволяет совершить транзакцию, если один оператор потерпел неудачу. Это отличается, например, в Oracle, где вы можете зафиксировать транзакцию, даже если промежуточный оператор DML не удался.
a_horse_with_no_name 07 апр. 2015, в 07:41
0

@a_horse_with_no_name При желании можно изменить поведение водителя в этом случае. PreparedStatement (о чем я и предполагаю, что этот вопрос) отправляются в виде одного сообщения Parse по сети, за которым следуют несколько сообщений Bind/Describe/Execute , по одному на каждую запись пакета. Если транзакция еще не открыта, она открывается с начальным значением BEGIN и завершением COMMIT . Сделать это в autocommit тривиально, исключив операторы оберточной транзакции.
Craig Ringer 07 апр. 2015, в 08:00
0

@a_horse_with_no_name Не только это, но и поведение протокола v3 соответствует тому, что хочет спецификация. Если в операторе есть ошибка, Pg будет сбрасывать остаток потока, пока не получит сообщение Sync от клиента. Поэтому нам не нужно беспокоиться о предотвращении выполнения последующих операторов после ошибки - что-то, что допускает спецификация, но на практике это ужасная идея.
Craig Ringer 07 апр. 2015, в 08:01
0

@a_horse_with_no_name Так что, если ОП может показать убедительную причину, по которой текущее поведение водителя является неправильным, я не вижу, что его особенно сложно изменить, если только нет складки, которую я где-то пропустил.
Craig Ringer 07 апр. 2015, в 08:02
0

спасибо за ваши ответы .. @CraigRinger, если возможно, я проверю другие поведения драйверов .. Я был просто обеспокоен спецификацией JDBC. Когда мы используем метод executeUpdate для PS, мы используем его документацию. Насколько я понял, успешные вставки должны быть сохранены, и выполнение дополнительных вставок после сбоя зависит от драйвера. Ссылка, которой я поделился выше, также говорит о том же самом, не так ли?
Mukesh Negi 07 апр. 2015, в 12:24
1

Ребята, я забыл упомянуть, что успешные вставки не отменяются, если мы используем Statement.RETURN_GENERATED_KEYS. Эта вещь добавляет мне путаницы.
Mukesh Negi 07 апр. 2015, в 13:15
0

@MukeshNegi Хм, это пахнет как ошибка. Можете ли вы создать тестовый пример JUnit, возможно, в виде патча, добавив еще несколько случаев в org/postgresql/test/jdbc2/BatchExecuteTest.class в дереве исходного кода драйвера?
Craig Ringer 07 апр. 2015, в 13:46
0

Если мы используем Statement.RETURN_GENERATED_KEYS, все операторы выполняются один за другим. Это намного медленнее, как всегда в режиме автоматической фиксации. Реальный смысл выполнения как пакета состоит в том, чтобы заставить их всех вести себя как одно единственное утверждение, которое не может быть успешным по частям.
Holger Jakobs 06 май 2017, в 19:25
0

@HolgerJakobs На самом деле они могут выполняться по одному, в зависимости от того, может ли драйвер определить ширину возвращаемых типов данных. Я настоятельно рекомендую вам избегать пакетов в режиме автоматической фиксации.
Craig Ringer 07 май 2017, в 03:39

Показать ещё 7 комментариев