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

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

AGK>Абстрагироваться от хранилища?! А Вы действительно считаете это возможным??! (в этом случае я говорю про БОЛЬШУЮ систему — Переход от от MS SQL к Oracle будет очень проблематичен и все равно займет много времени и денег, а особенно, когда все размыто в коде...., для этого должна быть очень существенная причина) А оно надо?! И Вы действительно считаете, что система, которая обслуживает ОЧЕНЬ много запросов и итак работает на кластере (16,4-х процессорных) с более-менее приемлимой производительностью, тосле такого "абтсрагирования" не "умрет"?!

Я разве сказал, что она не "умрет", я ж не знаю ни специфики запросов ни объема данных, в исходном посте про это не было ничего. Если нужна супер производительность используйте хранимки с оптимизацией запросов под конкретную БД. Возможно даже удасться прикрутить Hibernate или JDO в них такая возможность есть, можно и свои запросы указывать AFAIK, иначе JDBC+Spring. Нет серебряной пули, каждое средство надо применять под свои цели. Если у меня нет терабайтов передаваеммых данных и тысяч одновременных запросов, зачем мне париться с SQL, когда я реализую модель в классах и все, остально за меня сделает ORM-средство?

AGK>Мой сервисный слой органиован в виде COM+ компонентов, поэтому там также декларативное управление транзакциями.
AGK>Или может с подобным в Java туговато? Здесь поподробнее, пожалуйста.....

Сомневаюсь, что в Java есть проблемы — стоит лишь набрать declarative transaction management и вывалится куча ссылок для J2EE. В JDBC управление транзакциями (создание, коммиты, откаты) прописывается ручками в коде, в J2EE приложениях как правило в соотв. дескрипторе приложения.