Использую вложенные транзакции при работе через ADO следующим образом:
- открываю соединение
- посылаю BEGIN TRANSACTION (пробовал и через begintrans/committrans - тот же эффект)
- выполняются всякие разные изменения связанных данных в базе (в т.ч. через сложные хранимки, где могут быть свои транзакции)
- посылаю COMMIT TRANSACTION
Соединение явно не закрываю и в ряде случаев при отмене транзакции не посылаю ROLLBACK, предполагая что он сделается неявно (как и закрытие соединения) при выходе из контекста создавшего соединение (который происходит тут же) - т.е. при уничтожении переменной соединения

Но, как оказалось, не тут-то было. Выяснилось, что по дефолту ADO не уничтожает такие соединения а помещает в пул и переиспользует. В результате на практике наблюдается интересная картина - если транзакция осталась незавершенной, то дальше в этом соединении могут происходить чудеса, механику которых я затрудняюсь объяснить. Когда в новой транзакции (с точки зрения посылающей стороны) происходит фиксация предыдущей незавершенной транзакция и часть новой. И так далее. Сайд-эффекты зависят от поведения пула.
Теоретически я конечно могу пытаться всегда когда надо откатывать транзакции и закрывать соединение явно, но на практике я все равно не могу этого гарантировать, поэтому хотелось бы чтобы неявное закрытие соединения приводило к его уничтожению с откатом незавершенных транзакций (фиг с ним, с затратами на создание соединений, не смертельно).

Нашел, что отключить сервис пула ADO можно через реестр и в строке соединения, установив опцию OLE DB Services=-2
Пока прописал в строке соединения, сижу наблюдаю... В реестре боюсь установить не там где надо, так как не до конца понимаю для какого провайдера прописать (в строке соединения у меня просто driver={SQL Server} прописано).
В чем вопрос, собственно. Встречал еще рекомендации установить OLE DB Services=-4. Это типа кроме пула соединений ADO отключает еще и некий "Automatic Transaction Enlistment", по которому что-то не шибко гуглится.
Скажите пожалуйста, кто в курсе, как именно изменится поведение при его отключении.
Ну и буду рад любым комментариям, способным помочь разобраться с ситуацией.

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

Владислав Колосовfisher,
Вы выполняете сценарий "солнечного дня" и полагаетесь на неявное поведение функций. Во избежание проблем необходимо применять полный контроль над транзакциями и ошибками, в частности, в обработчике ошибок кода выполняться проверку счетчика транзакций открытого соединения и, если оно > 0, выполнять ROLLBACK.
Наборот. Я хочу чтобы при любом сценарии когда "что-то пошло не так", вплоть до краша приложения, незавершенная транзакция была гарантированно отменена.

Владислав Колосовfisher,
При краше приложения пул будет уничтожен и транзакции откатит сервер.
Этого не происходит. Пул держит не приложение. Это подсистема OLEDB.

Владислав Колосовfisher,
чудеса пишете. У Вас отдельное приложение для связи с сервером? Как у Вас живет класс вне приложения?
Эти чудеса, к сожалению, приходится наблюдать :)
COM-компоненты - это не совсем классы. Это довольно хитрые приложения, с которыми можно работать подобно классам.

Формулировки открытым текстом, что пул ADO не является частью приложения я не нашел, но здесь есть интересная формулировка:
авторConnections are pooled per process, per application domain , per connection string and when integrated security is used, per Windows identity.
Если бы пул существовал только в рамках приложения, то к чему бы было это упоминать? Кстати, там же упоминается, что явное закрытие соединения (close) не уничтожает соединение, а гарантированно возвращает его в пул.
Аналогичное упоминание (про сепарацию соединений в пуле "per application") нахожу и в других источниках.
Нашел, кстати, старую ветку где чел безответно задавал похожие вопросы.

invmfisher,
Почитайте, что такое домен приложения.
Почитал. И как это работает против моего предположения?

Предлагаю пока прервать обсуждение. Обсуждаемый вопрос для меня важен, потому как я наблюдал поведение которое не могу объяснить иначе и хочу найти объяснение, так как чудес не бывает. Но этот вопрос подождет.
Гораздо важнее для меня прямо сейчас ответ на заданный ранее вопрос:
Что произойдет при указании OLE DB Services=-4? Как изменится поведение соединений? Что такое "Automatic Transaction Enlistment" в данном контексте?

alexeyvgfisherКстати, там же упоминается, что явное закрытие соединения (close) не уничтожает соединение, а гарантированно возвращает его в пул.При закрытии соединения, и возврате его в пул, транзакция гарантированно откатывается.

У вас, очевидно, проблема в том, что при крахе вашего приложения то, другое приложение, не выполняет Close.

Возможно. Это было просто к слову, что даже при явном "закрытии" соединения оно на самом деле не закрывается при наличии пулинга.

alexeyvgfisherВыяснилось, что по дефолту ADO не уничтожает такие соединения а помещает в пул и переиспользует. В результате на практике наблюдается интересная картина - если транзакция осталась незавершенной, то дальше в этом соединении могут происходить чудеса, механику которых я затрудняюсь объяснить. Когда в новой транзакции (с точки зрения посылающей стороны) происходит фиксация предыдущей незавершенной транзакция и часть новой. И так далее. Сайд-эффекты зависят от поведения пула.Или вы путаете (используете неподходящщую терминологию), называя "пулом коннектов" такие ситуации, когда ADO оставляет открытые коннекты (т.е. не возвращает их в пул).

Все возможно. Я уже мало что понимаю. Мой мозг взрывает не наличие соединений с незавершенными транзакциями, а возможность продолжения этих транзакций после повторного соединения, которое логика программы совершенно логично ожидает как "девственное" с точки зрения возможных сайд-эффектов. То есть их быть не должно. А они есть. Я своими глазами наблюдал при переподключении и отработке новых транзакций фиксацию транзакции, начатую полчаса назад. Полчаса, Карл!

invm, Я застрял на попытке перевода и осознания фразы
Enlist - 'true'. When true, the pooler automatically enlists the connection in the current transaction context of the creation thread if a transaction context exists.