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

[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

[metaclass.livejournal.com]

Для MSSQL это работает, известное дело.
Интересно, почему оно не является поведением по умолчанию.

[denisioru.livejournal.com]

Да, и особенно весело с MARS, когда используется Application Roles

[norguhtar.livejournal.com]

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

[metaclass.livejournal.com]

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

Но вот невозможность читать из двух SQL запросов одновременно - это какой-то бред тяжкий, имхо.

[norguhtar.livejournal.com]

И как вы себе представляете одновременное чтение из двух SQL запросов в одном подключении? С моей точки зрения это приведет к неоправданному усложнению кода как со стороны сервера так и со стороны клиента.

[metaclass.livejournal.com]

А в чем сложность то? Всю жизнь в дельфи+firebird так делали. Препарим два запроса, один выполняем, читаем в цикле, внутри цикла выполняем другой, читаем во вложенном цикле.
В API это выглядит как создание запроса, получение его хендла и затем использование этого хендла первым параметром во всех функциях(prepare, fetch, close).

[norguhtar.livejournal.com]

В реализации. В случае соединения разделение транзакций и получения и отправки данных ложится на tcp/ip. В случае же одного соединения, надо будет городить это разделение внутри соединения, что приведет к усложеннию кода как со стороны клиента, так и со стороны сервера.

[metaclass.livejournal.com]

Встречный вопрос: как без этого функционала сделать ленивую обработку двух таблиц - основной и подчиненной. Какое-нибудь элементарное задание вроде "обработать 10 млн проводок с детализацией"

[norguhtar.livejournal.com]

use connection pool luke!
Я вот вообще этим не запариваюсь. У меня JPA это все делает.

[volodymir-k.livejournal.com]

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

Попробуйте продумать алгоритм расчёта зарплат для 20 тыс.рабочих согласно белорусскому законодательству, желательно в пределах 3 часов. Могу примерно припомнить исходные таблицы:
- журналы рабочего времени по видам работ
- тарифы по видам работ
- таблица совместителей
- накопленные налоги по сотрудникам за последние 2 года
- справочник МРОТ по месяцам
- справочник налогов по месяцам
- справочник размеры пособий по уходу за ребенком
- выплаченные пособия за ребенком
- больничные листы
... где-то ещё штук 20 таблиц, забыл уже.

[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 реализован.

[metaclass.livejournal.com]

Интересно, как в JPA этот вопрос обходят. Подозреваю, что таки исключительно непересекающимися фетчами результатов.

[norguhtar.livejournal.com]

Где так и есть. Только вот ленивые запросы там с осторожностью надо использовать иначе можно на больших объемах словить пачку запросов в базу.

[norguhtar.livejournal.com]

Кстати да. Я тут подумал. А что мешает использовать join запрос?

[metaclass.livejournal.com]

И что это будет? Денормализованный датасет типа "на каждую запись в детализации (коих over 9000) повторяем запись-владелец"?

[norguhtar.livejournal.com]

Да. А дальше обрабатываем. В чем собственно проблема? В том что с этим не удобно работать?

[metaclass.livejournal.com]

В том что это маразм, очевиднейший. Сначала делаем декартово произведение, денормализуем, сосем по не самому быстрому каналу на клиента увеличенный по сравнению с нужным результат, а потом его нормализуем обратно, закатывая солнце вручную.
Проще уж на сервере все обработать тогда, ничего на клиента/миддлварь не вытаскивая.

[norguhtar.livejournal.com]

Если у вас обрабатываются все данные это самый быстрый способ их получить и обработать. Если выборочно относительно того какие данные в первой таблице, то можно делать отдельный ленивый select. Опять же никто offset и limit не отменял.

[vp.livejournal.com]

Не, это явный перебор.
Приемлемо ТОЛЬКО в случае, когда ну вообще никаких средств не осталось..

[norguhtar.livejournal.com]

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

[metaclass.livejournal.com]

Пиздец-пиздец будет только в кривых серверах, которые не умеют запросы препарить и держать отпрепаренными. Таблица по всякому будет в кэше сервера, если запрос не закрывать каждый раз - оно летает, проверено.
Другое дело что, судя по всему, ADO.NET это корректно делать не умеет, т.к. затачивалась под кривые сервера, коих большинство.

[norguhtar.livejournal.com]

Вообще время работы первого запроса будет ниже чем суммарное время второго. Вообщем как делать сильно зависит от того что делать. Ну и к слову JPA умеет из join который я привел разворачивать два объекта, так что с точки зрения удобства тут все в порядке.

[vp.livejournal.com]

ADO ж вообще задумывался как обобщенный интерфейс к БД. Вот скорее всего они и привели его к наименьшему общему знаменателю, выкинув такого рода фичи серверов, которые не обобщаются.

[molnij.livejournal.com]

Если такое "подключение" умеет единственно - выполнять ровно один запрос, то лично у меня возникает вопрос в его смысле. Можно смело выкинуть подключение оставив запрос\команду\etc упростив многоэтажный пирог абстракций доступа к данным и не потерять ничего.

[norguhtar.livejournal.com]

Последовательно оно умеет сколько угодно. Параллельно надо вписывать уже фабрику подключений.

[volodymir-k.livejournal.com]

В далёком 1998 году, в обсуждении компонент Дельфи, один мегаэксперт Толя Тенцер высказал своё мнение, что у MSSQL Server банально проблема с потоковым протоколом. Не предусмотрена фича по дизайну, и не реализована в протоколе. Кстати дизайн Микрософт тоже унаследовал от Сайбейза. И в принципе, SQL как придуманный в 1980-х язык не предусматривал современных фич типа авторизации, постраничной выгрузки и т.п., о многопотомности вообще никто не думал. Нужны 2 транзакции - берите два соединения.

В принципе, Вы можете сами посмотреть доки по jtds проекту, там описываются протоколы, скорее всего фича корректно не получится.

[plumqqz.livejournal.com]

Иначе я не могу объяснить тот факт, что в некоторых серверах невозможно открыть одновременно две транзакции в одном соединении.

Не вполне понимаю, что мешает открыть два соединения. Или сорок четыре, если требуется.

[metaclass.livejournal.com]

Не, с транзакциями это не так сильно мешает, хотя и маразм.
А вот два запроса в одной транзакции-соедиении - это что-то невменяемое.

[plumqqz.livejournal.com]

Ну, открыть два соединения и пустить там по запросу - в чем проблемы?

[metaclass.livejournal.com]

А транзакцию куды? Я ж хочу чтобы запросы были в одной транзакции, чтобы консистентное состояние БД видеть.

[molnij.livejournal.com]

А какая связка умеет делать две транзакции внутри одного соединения?
Просто, насколько помню встречавшиеся мне варианты транзакции везде не имеют собственных хэндлов(следствие стандата SQL?) и тогда неясно, как указывть транзакцию для очередного выполняемого запроса.

[metaclass.livejournal.com]

Firebird умеет. Судя по всему что здесь пишут, это единственный сервер, который это умеет.

[molnij.livejournal.com]

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

[metaclass.livejournal.com]

Да, хендл транзакции отдает апишная функция что-то вроде start_trans.
Сессия это дорогой объект - новый коннект к базе данных тяжел. А транзакция поверх уже существующего коннекта дешевле.

[metaclass.livejournal.com]

В стандарте SQL про API ничего не сказано вроде.

[volodymir-k.livejournal.com]

ODBC как раз такое API, вроде бы часть стандарта.

[zamotivator.livejournal.com]

Ага, Microsoft слабало какую-то хуйню, а потом её застандартизировало.
Хуйнёй и вуду оно от этого быть не перестало.

[volodymir-k.livejournal.com]

В моей реальности последовательность была немножко иной:
ODBC uses as its basis the various Call Level Interface (CLI) specifications from the SQL Access Group, X/Open (now part of The Open Group), and the ISO/IEC.
1.0: released in September 1992[4]

The work with the Call Level Interface began in a subcommittee of the US-based SQL Access Group.

The SQL Access Group (SAG) was a group of software companies that was formed in 1989 to define and promote standards for database portability and interoperability. Initial members were Oracle Corporation, Informix, Ingres, DEC, Tandem, Sun and HP.

Так что слабал не микрософт.

[belpartizan.blogspot.com (from livejournal.com)]

Про .Net ничего не скажу, но в Java:

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

2) Параллельные ResultSet поддерживаются на одном коннекте (я не припомню проблем с параллельным разбором нескольких одновременно)