Как же удолбут.

[metaclass]

Тема "сессий" и "транзакций" при подключениях к различным базам данных судя по всему является очередным потаенным вуду для разработчиков. Причем даже для разработчиков самих БД и драйверов доступа к ним.

Иначе я не могу объяснить тот факт, что в некоторых серверах невозможно открыть одновременно две транзакции в одном соединении. Или то, что из трех ADO.NET провайдеров (Firebird, MSSQL, Postgresql) одновременно открыть два SQL запроса в одном соединении и читать одновременно из них - можно только в Firebird, два остальных ругаются типа "уже открыт DataReader".

Ну вот вопрос как в ADO.NET ленивым образом (не загружая в память) прочитать список сущностей из БД, и для каждой сущности прочитать вложенные для нее?
Ну всегда обычное решение было - цикл по одному DataReader, из него берем некое поле, подсовываем его значение в параметр второй команде, выполняем ExecuteReader и пытаемся читать во вложенном цикле. В Firebird работает, в других хрен.

PS: В Npgsql есть параметр PreloadReader=true, который позволяет обойти это ограничение и который не рекомендуется использовать, т.к. он грузит весь DataReader в память и смысл ленивой итерации теряется. И написано, что это ограничение - by design, упомянуто в доке на ADO.NET.

По моему, архитекторов ADO.NET надо убить, это же идиотизм клинический.

Comments

[norguhtar.livejournal.com]

Это и называется быдлокодинг. Если программер работает на БД с 20 записями и верит, что 10 млн строк это то же самое.

Это называется вы не знаете чем, я занимаюсь :)


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

Я вам могу встречную задачу по тарификации услуг доступа к сети предложить. Какое это имеет отношение к JPA и connection pool?

[volodymir-k.livejournal.com]

> Какое это имеет отношение к JPA и connection pool?

Вы всё еще не догадались???
Я намекаю, что программер должен не высасывать сразу все данные в память, а читать кусками; для этого и нужно понимание, какие соединения делают какие транзакции, вместо тупого использования connection pool.

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

[norguhtar.livejournal.com]

Я намекаю, что программер должен не высасывать сразу все данные в память, а читать кусками; для этого и нужно понимание, какие соединения делают какие транзакции, вместо тупого использования connection pool.

Вы шо считаете меня идиотом да? Вообще в JPA для ограничения идиотов по умолчанию фетчится только первая 1000 строк. Да и я не фетчу 1000 строк при таких обновлениях.



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

В случае batch достаточно и одного подключения. Как бе у меня подразумевается обычно:

Одно подключение для длинных транзакций
N-подключений для множества коротких одновременных транзакций

[vaddimka.livejournal.com]

мне кажется, вы не совсем понимаете всю концепцию connection pool'ов.
пул никак не связан со способом фетча данных.
можно читать результаты тяжелого запроса в одном подключении, дергать множество мелких - в другом. то же самое с несколькими транзакциями
Ребе, вероятно, смутило что ранее он использовал некое API, которое менеджило подключения к БД за него; с другой стороны все решается достаточно примитивным врэппером.

[metaclass.livejournal.com]

Оно ничего не менеджило, это нативная фича сервера и клиентской либы. Соединение там в норме одно на весь сеанс работы.

[vaddimka.livejournal.com]

А, круто. Интересно как там interleaving реализован.