Задумался тут - кто как реализовывает механизм транзакций/сессий.

Во всех примерах, которые я видел, создают одну сессию на один запрос с клиента и по транзакции на каждый запрос к базе.
Мне логичней кажется, чтобы транзакция тоже была одна. Например, хотим сохранить 20 новых объектов, но на 10-м сваливаемся с ошибкой и в этом случае транзакцию не откатить и 9 объектов будут созданы. Мне кажется более приемлимым создавать транзакцию на входе в сервлет и делать коммит на выходе. Или я неправильно понимаю эти механизмы? Выскажитесь по этому поводу.

Если вы хотите вставку 20 обьектов осуществить в одну транзакцию, то и рассматривать их придется, очевидно, как один обьект, т.е. коллекцию. Клиент пересылает в сервлет коллекцию. Пока вся коллекция не получена сервлетом, никаких операций вставки в базу не происходит. Посередине пересылки может произойти обрыв соединения и надо начинать все сначала. Если соединение ненадежное, а коллекция большая, то такие неудачные попытки могут быть бесконечны.  

0. Сервлет - это не то место, где должна быть бизнес логика, сервлет - это обработка события на View.
1. Самая распространенная схема - это один запрос от клиента создает одну транзакцию.
2. Транзакциями управляет обычно уровень Сервисов, однако можно это делать и в Фильтре, так называемый Open Session In View (есть две схемы этого шаблона, тебе нужна та, которая работает без re-attache объектов к сессии). Однако тем не менее уровень сервисов должен все равно быть транзакционным, для того, чтоб понять как одновременно и Фильтр и Сервис мог управлять транзакциями, нужно посмотреть на Transaction Propagation в спринге и что они дают.

Привет. Ничего смертельного в твоем желание нет: это архитектура, которая имеет право на жизнь.
Раньше это был SessionFacade.
Теперь есть более крутые решения Seam managed transactions
Вот мой пример более легкого решения "Транзакция на запрос" через фильтр. Но правда с помощью Spring:
TransactionFilter.java

Spring context

web.xml

Теперь у нас есть транзакция от начала запроса до конца ответа.
Плюс таким образом я победил LazyInitializationException

Авось да будет полезным

Еще вариант без спринга Как я победил LazyException