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

SM>> Нет напряга. Вообще никакого.
IB>Вот я своими глазами видел как SAP-овское приложение, по такой схеме, кладет Оракл на 25-30 пользователях совершенно без напряга. Ну, ребята нашли простой выход, они на этот продукт больше 20 лицензий не продают... Вы так же поступаете?

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

IB>>>T1 видит эти изменения?
SM>> После коммита T2?
SM>> Конечно.
IB>Ты за него не отвечай, он сам справится.

Грязных чтений в ФБ нет, а видимость изменений будет зависеть от настроек. Справился?
Только вот какое отношение это все имеет к поднятому вопросу?

SM>> Вопрос в другом. В удобстве разработки и построения архитектуры приложения, используя данные возможности.
IB>О! Так вот я тебе как краевед скажу. Разрабатывать архитектуру приложения, когда ты четко знаешь, что у тебя на одну активную транзакцию одно подключение и это дешево — очень удобно.

Ну, тоже самое можно сказать и наоборот — вопрос привычки и наработанных решений, не так ли?

SM>> Так вот на текущий момент времени IB/FB располагает достаточной гибкостью в этом плане.
IB>Ну правильно, освоили пулинг, появилась гибкость и человеческий подход, без изнурительных приседаний вокруг одного соединения.

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