DPH3Mad_HeadКак по мне - это фраза из разряда "программировать или верстать нужно в блокноте". Просто более высокоуровневые фреймворки нужно изучать и разбираться, что происходит от того или иного действия. А иначе получается преждевременная оптимизация, а это очень большое зло. У меня на прошлой работе были программисты старой школы которые на JDBC + собственное ручный DAO слой исполдьзовали везде. Так они эту часть писали в 3 раза дольше, чем другая команда использующая ORM и в узких местах написавшая native query.

Ну, когда я смогу найти на рынке за разумные деньги разработчика, которые понимает, как работает @Transactional поверх Hibernate на конкретной СУБД (кстати, я пока еще таких вообще не видел, как только начинаешь задавать сложные вопросы - все начинают говорить "наверно все будет хорошо"), то да, наверно можно будет спокойно использовать ORM. А на данный момент ответственные или высокопроизводительные вещи проще писать без ORMа. Кстати, как только нужно работать с изменением структуры СУБД в кластере без останова - то ORM начинает изрядно тормозить разработку. Выигрыш в производительности разработки - только пока в продакшн не вышли, да и то если на jdbc писать совсем не раздумывая. Проверялось )
а можно спросить что за конкретные вопросы по "как работает транзакшнл". да еще и на конкретной субд??