Использование нескольких объектов операторов в многопоточном приложении - PullRequest
1 голос
/ 08 июля 2011

Я разрабатываю многопоточное приложение, в котором разные потоки требуются для одновременного обновления базы данных. Следовательно, я передал новый объект оператора каждому потоку, создавая его (чтобы избежать блокировки, если я отправляю один объект). Мои сомнения:

  1. Существует ли ограничение на количество объектов операторов, которые могут быть получены из одного соединения jdbc? будет ли соединение с базой данных потерпеть неудачу, если я создаю слишком много объектов операторов?

  2. Если я правильно закрою оператор до того, как поток закончится, каково будет количество потоков, которые могут быть созданы за один раз (в системе с 512 МБ ОЗУ)?

  3. Не будет ли драйвер обновлять базу данных, сохраняя согласованность данных, независимо от того, сколько объектов операторов я использую для параллельного обновления БД? я использую mysql.

Ответы [ 3 ]

2 голосов
/ 08 июля 2011

Хотя я не программист java, разделять одно соединение между несколькими потоками - плохая идея. Что происходит, когда 2 потока пытаются писать в одном сокете? - так - каждый поток должен иметь свое собственное соединение с БД

Да, данные должны быть согласованы в БД, если многие потоки пишут одновременно - в любом случае вам придется позаботиться о коде правильного управления транзакциями - и, конечно, использовать InnoDB в качестве механизма хранения MySQL, потому что MyISAM не разрешает транзакции

2 голосов
/ 08 июля 2011
  1. Практически количество объектов операторов, которые вы сможете создать, должно соответствовать вашим потребностям. Опять же, сколько "слишком много" в вашем случае?
  2. Количество создаваемых потоков зависит от lot факторов. Поймите, что эти потоки, которые вы создаете, будут потоками уровня ОС, а не потоками real (при условии, что у вас есть двухъядерная система, это сделает 2 аппаратных потока или 4, если доступна гиперпоточность). Профилирование здесь будет иметь первостепенное значение, чтобы определить, сколько потоков можно создать, прежде чем ваша система замедлится до сканирования.
  3. Это будет зависеть от механизма блокировки, используемого базой данных. К чему вы стремитесь; высокая целостность или высокая производительность? Прочитайте это .

IMO, вам лучше было бы искать объекты Соединения из пула соединений в каждом из этих потоков, а не пытаться обойти объекты "оператор".

1 голос
/ 08 июля 2011
  1. это, вероятно, зависит от реализации jdbc, но, в общем, почти все имеют ограничения.
  2. кто знает. на практике, наверное, тысячи. однако, многие из них, вероятно, не повысят вашу производительность.
  3. да, вы должны иметь возможность совместно использовать 1 соединение в нескольких потоках, однако многие реализации jdbc работают плохо в этом сценарии. лучше иметь соединение на поток (для некоторого разумного количества соединений / потоков).
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...