Firebird Параллельные транзакции - Базы данных

Как известно, Firebird .NET Data Provider не поддерживает параллельные транзакции.

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

Здравствуйте, mmaxx, Вы писали:

M>Как известно, Firebird .NET Data Provider не поддерживает параллельные транзакции.
M>В моем многопотоковом приложении идет работа с единым соединением, пришлось обойтись блокировками. Нет ли другого провайдера под сию БД, чтобы можно было обойтись параллельными транзакциями?
А что в одном соединении можно 2 транзакции открыть?

Здравствуйте, mmaxx, Вы писали:

M>Как известно, Firebird .NET Data Provider не поддерживает параллельные транзакции.

M>В моем многопотоковом приложении идет работа с единым соединением, пришлось обойтись блокировками. Нет ли другого провайдера под сию БД, чтобы можно было обойтись параллельными транзакциями?

Как это не странно, но есть. И более того — с поддержкой многопоточных приложений. Но это OLEDB провайдер.

Правда я не знаю как в нете (через OLEDB.NET) соорудить две параллельные транзакции

Вот если бы речь шла про ADODB (ActiveX), я бы тебе точно сказал как поступить. К сожалению, уроды из MS не портировали в OLEDB.NET одну замечательную лазейку старого, доброго ADO

... А написать другую, нормальную реализацию OLEDB.NET (с параллельными транзакциями, именноваными параметрами и т.д и т.п) у ленивого Меркулова руки не доходят

Здравствуйте, IZM, Вы писали:

M>>Как известно, Firebird .NET Data Provider не поддерживает параллельные транзакции.

IZM>А что в одном соединении можно 2 транзакции открыть?

"Нет, сынок, это фантастика." (с) реклама хохландского сыра

Здравствуйте, IZM, Вы писали:
M>>Как известно, Firebird .NET Data Provider не поддерживает параллельные транзакции.
M>>В моем многопотоковом приложении идет работа с единым соединением, пришлось обойтись блокировками. Нет ли другого провайдера под сию БД, чтобы можно было обойтись параллельными транзакциями?
IZM>А что в одном соединении можно 2 транзакции открыть?
Можно открыть несколько соединений.
Можно посмотреть на OLE DB провайдер — хотя я не нашел там такого.
Можно доработать напильником код Firebird .NET Data Provider.

... << RSDN@Home 1.2.0 alpha rev. 746>>

Здравствуйте, Tonal-, Вы писали:

IZM>>А что в одном соединении можно 2 транзакции открыть?
T>Можно открыть несколько соединений.
T>Можно посмотреть на OLE DB провайдер — хотя я не нашел там такого.

В OLEDB изначально (то есть в самой спецификации) предусмотрена возможность создания нескольких независимых транзакций в рамках одного соединения. IB/FB такие вещи поддерживают. IBProvider, соответственно, тоже. Если бы я не использовал это в течении последних семи лет, я бы начал сомневаться... То что верхний уровень такой тупой и урезает эту функциональность, ну так я даже знаю почему. Влияние убогости интерфейса MSSQL играет не последнюю роль. Хотя основное влияние, полагаю, оказывает пул подключений.

Вот щас появится какой нибуть перец, который спросит — "а ты точно уверен, что ты именно параллельные транзакции используешь? ... Это же нонсен... Может все таки несколько подключений создается или у тебя там вложенные транзакции ..."

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

T>Можно доработать напильником код Firebird .NET Data Provider.

Ага, нашел что посоветовать

Здравствуйте, mmaxx, Вы писали:

M>В моем многопотоковом приложении идет работа с единым соединением, пришлось обойтись блокировками. Нет ли другого провайдера под сию БД, чтобы можно было обойтись параллельными транзакциями?

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

Здравствуйте, max314, Вы писали:

M>Здравствуйте, mmaxx, Вы писали:

M>>В моем многопотоковом приложении идет работа с единым соединением, пришлось обойтись блокировками. Нет ли другого провайдера под сию БД, чтобы можно было обойтись параллельными транзакциями?

M>Меня всю жизнь мучает вопрос, Чем паралельные транзакции отличаються от 2-х соединений в каждой по транзакции?

Есть такая архитектура "Classic Server". На каждое соединение создается отдельный процесс на сервере.

Здравствуйте, max314, Вы писали:

M>>В моем многопотоковом приложении идет работа с единым соединением, пришлось обойтись блокировками. Нет ли другого провайдера под сию БД, чтобы можно было обойтись параллельными транзакциями?

M>Меня всю жизнь мучает вопрос, Чем паралельные транзакции отличаються от 2-х соединений в каждой по транзакции?
В общем — архитектурой.
Если интересует теория, то тебе сюда:
http://www.osp.ru/os/2005/01/185218/

... << RSDN@Home 1.2.0 alpha rev. 743>>

Здравствуйте, max314, Вы писали:

M>Меня всю жизнь мучает вопрос, Чем паралельные транзакции отличаються от 2-х соединений в каждой по транзакции?

а зачем для новой транзакции открывать новое соединение????

тут уже привели в пример классик, но еще пример — стоимость открытия соединения
по сравнению со стоимостью старта транзакции. Допустим, могут быть даже лимиты
на число соединений — и что тогда?

Кстати, позволю себе риторически выразиться. Мы уже имеем искривленные
блокировочниками уровни изолированности транзакций в стандарте.
http://emanual.ru/download/www.eManual.ru_538.html
Хорошо хоть версионность сейчас почти у всех есть, поэтому транзакции
уровня snapshot уже никого не удивляют.

А теперь мы имеем идиотическую архитектуру практически всех популярных
драйверов, где только одна транзакция на соединение. Опять же, радует
что потихоньку это начинает меняться как в серверах, "определяющих моду".
Глядишь, и архитектура драйверов будет получше.

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

Здравствуйте, Кузьменко Д.В., Вы писали:

КДВ>а зачем для новой транзакции открывать новое соединение????
Затем, чтобы не хранить старое соединение. Открыть новое существенно проще.

КДВ>тут уже привели в пример классик, но еще пример — стоимость открытия соединения
КДВ>по сравнению со стоимостью старта транзакции. Допустим, могут быть даже лимиты
КДВ>на число соединений — и что тогда?
Вспоминаем про существование пулинга.

КДВ>А теперь мы имеем идиотическую архитектуру практически всех популярных
КДВ>драйверов, где только одна транзакция на соединение.
Это правильная архитектура.

... << RSDN@Home 1.2.0 alpha rev. 673>>

Здравствуйте, kdv, Вы писали:

КДВ>тут уже привели в пример классик, но еще пример — стоимость открытия соединения
КДВ>по сравнению со стоимостью старта транзакции.

Спорил недавно с другом на эту тему — не для всех СУБД это аргумент, в некотрых, гм,
"СУБД" это очень дешевое действие, в пример он мне приводил MySQL.
Хотя, конечно, стоимость была моим основным аргументом

Кузьменко Д.В. пишет:
> По большому счету это классика. Сначала какое-нибудь г... становится
> популярным
> на безрыбье, а потом все мучаются, героически преодолевая трудности.

Вы имеете в виду вышеуказанную кривизну Interbase Classic Server,
где создание нового соединения порождает новый процесс на сервере,
потому что в СУБД из-за наличия глобальных переменных по-другому
нельзя обработать парралельные запросы от нескольких клиентов ?