2015-12-30 1 views
4

смотрите комментарии в весеннем DataSourceTransactionManager.java, функция doBegin:Должна ли автокоммутировать источник данных false?

// Switch to manual commit if necessary. This is very expensive in some JDBC drivers, 
// so we don't want to do it unnecessarily (for example if we've explicitly 
// configured the connection pool to set it already). 
     if (con.getAutoCommit()) { 
      txObject.setMustRestoreAutoCommit(true); 
      if (logger.isDebugEnabled()) { 
       logger.debug("Switching JDBC Connection [" + con + "] to manual commit"); 
      } 
      con.setAutoCommit(false); 
     } 

В проекте я работаю, автокоммит не настроен. Это верно по умолчанию. Мы используем Spring для управления транзакциями, и все SQL-запросы выполняются в аннотированных функциях @Transactional. Таким образом, транзакции осуществляются вручную. Каждый раз, когда начинается транзакция, соединение db устанавливается на autocommit на false, а после завершения транзакции autocommit возвращается к true. Типичным рабочим процессом будет (на уровне JDBC):

  1. conn = dataSource.getConnection();
  2. conn.setAutoCommit (false);
  3. stmt = conn.createStatement();
  4. stmt.executeQuery (...);
  5. conn.commit()/conn.rollback();
  6. conn.setAutoCommit (true);

Устанавливает ли автоколонну взад и вперед дорого? следует ли конфигурировать пул соединений datasource пул autocommit = false для повышения производительности? пропустить шаг 2 и этап 6.

ответ

0

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

SET autocommit=0; 
your code here.... 
SET autocommit=1; 

Update:

Как @codemania объясняется очень хорошо, что даже есть возможность отключить AutoCommit согласно вашему требованию, но вы не должны делать это. Даже это основная потребность в транзакции для успешного выполнения набора инструкций или отката, если вы отключите его тогда, как вы его достигнете.

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

+0

Я отредактировал мой вопрос, чтобы было ясно. – ShadowDancer

3

1) autocommit полностью зависит от базы данных, что означает, что каждое заявление через соединение будет выполняться в отдельной транзакции, которая неявно выполняется. Пока и до тех пор, вы не хотите использовать персональное кодирование и избегаете блокировки, хранящиеся в нескольких заявлениях, которые могут привести к конфликтам с другими пользователями, нет необходимости устанавливать для autocommit значение false.

2) Из точек зрения производительности,

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

b) могут быть случаи, когда вам необходимо откат.

c) вы хотите совершить транзакцию вручную на основе определенного условия.

EDIT: Я вижу, что вы отредактировали вопрос, чтобы ответить вам просто, autocommit = false заставит вас написать свой собственный commit/rollback/etc, производительность полностью зависит от базы данных, количество блокировок, хранящихся в момент в реальном времени!

№ установки автообмена в false и true снова не увеличит количество сборов в системе.

НЕТ, не подключайте пул соединений источника данных autocommit = false, если вы не делаете это по какой-то определенной причине и не являетесь опытным человеком. С точки зрения производительности, поскольку я уже деколирован, он зависит от типа базы данных и пользователей в режиме реального времени, обращающихся к базе данных в экземпляре, для вашего проекта, 99,99%, вам не нужно будет устанавливать его в false.

установка autocommit на true будет гарантировать, что commit вызывается после каждого утверждения.

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

Надеюсь, это помогло!

+0

Я думаю, что эти команды для набора autocommit нуждаются в двух поездках в оба конца и стоят дополнительно 0,8 миллисекунды за каждую транзакцию в моем тесте. – ShadowDancer

+0

логически, как я вижу, проблема будет при установке autocommit на true после завершения транзакции, которая содержит различные операторы, потому что вы снова сообщаете системе вернуться к состоянию по умолчанию и обрабатываете все по своему усмотрению, что не относится к тому, что вы устанавливаете autoocommit на false, так что может быть 1 roundtrip, а не два, которые стоили бы вам 0.8milli, хорошо также зависит от что вы делаете после этого setautocommit в true, если вы просто закрываете соединение, как это важно? : D – codemania23

0

Вы должны установить autocommit в true, когда вы отправляете транзакции базы данных. Транзакция базы данных - это логическая единица работы, которая обычно состоит из нескольких операций с базой данных (как правило, с несколькими обновлениями), и вы хотите, чтобы все они были успешными или все они потерпели неудачу. Если autocommit = false, ваши изменения не будут сохраняться до тех пор, пока вы не назовете commit() на объекте соединения, поэтому этот подход гарантирует, что все ваши обновления будут либо успешными, либо неудачными (путем вызова отката в случае исключения и т. Д.).

Если для параметра autocommit установлено значение true (по умолчанию), вы можете, например, изменить одну таблицу, но затем на второе обновление (будь то обновление/вставка или удаление), может возникнуть исключение, а вторая таблица не обновляется, тем самым оставляя вашу базу данных в несогласованном состоянии.

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

Смежные вопросы