Я юзаю коннект на подключение.
Транзакции тоже можно кидаь между подключениями. У меня так репликатор
работает. Сценарий такой:
- Скрипт на VBS создает подключение (ADODB) и стартует транзакцию
- передает его репликатору
- репликатор вытаскивает из него OLEDB-транзакцию и передает её (как
IUnknown) в рабочий поток. Без всякого маршалинга.
- рабочий поток возится с базой
- основной поток считывает состояние репликатора и ждет завершения его
работы
- репликатор заканчивает работу
- Скрипт смотрит на результат завершения работы и либо коммитит, либо
откатывает транзакцию
Б.я, в примерах провайдера есть код по параллельной закачке файлов в
блобы. В одной транзакции и (ясный пень) подключении.
Та охинея, с которой, я сейчас вожусь, тоже работает в одной
транзакции.
В Java многопоточность напрямую связана с транзакциями - каждый поток
имеет свою транзакцию (я здесь говорю о серверах приложений). При чем
"одновременно" могут работать несколько компонент (сервер приложений
синхронизирует сам, когда те "стартуют" транзакции) и каждая компонента
может сделать транзакцию "rollback only", т.е. пофиг кто-что там делал,
в конце-концов транзакция будет откачена. И этот механизм, с моей точки
зрения, лучшее что можно придумать.
В plan-vanilla JDBC можно конечно и из наскольких потоков к одному
коннекту лезть, но как раз там возникает проблема "а кто будет
коммитить?"...
У тебя почти как в Java, только одна транзакция. У нас же всегда (если,
конечно, правильно все сконфигурировать) используется двухфазный коммит,
посему каждый поток работает по своему подключению, а сервер приложений
коммитит все сам.
А вот чего не понял, так это того, где выигрыш от параллельной закачки
блобов в базу в одной транзакции. Ведь внутри ты где-то должен
синхронизироватся...
Роман
