О, спасибо)

Это было бы очевидно, если бы ты послушал в прошлый раз мой совет и почитал про проксирование

я читал, но глубоко вникать, копаться в кишках спринга не горю желанием

Во 1 там ничего сложного, во 2 это не совсем спринг

Кст для котлина есть мавен плагин allopen, который делает всё стереотипные компоненты и конфиги open

да я понимаю, что для проксирования нужна возможность переопределять методы. Просто не держал в голове, что у kotlin методы тоже закрыты

Там все закрыто по дефолту

я знаю. разве не понятно из того, что я пишу?

Ребят, а в jdbc autoCommit(true [def]/false) устанавливается только в рамках внешнего коннекта и не учитывается для вложенных?

Подробнее:
На примере банковской системы:
- 1. В DAO классе есть getCardByID(Long ID), который получает с БД объект класса Card.
- 2. Также в этом же DAO есть transfer(Card c1, Card c2, BigDecimal amount), который выполняет перевод денег с карты c1 на карту c2.

Для перевода денег в рамках одной транзакции должны быть выполнены проверки: карта принимающего должна существовать в системе, денег на счету отправляющего >= переводимой сумме.
По принципу DRY мне не следует внутри транзакции метода transfer заново описывать получение карты, а использовать готовый getCardByID

Суть проблемы:
Но останется ли тогда транзакция, выполняемая в рамках transfer(...) атомарной и согласованной? т.е. будет ли выполнятся блокировка ресурсов во время использования getCardByID внутри transfer() и вовремя выполнения самого transfer() для избегания феномена неповторяемого чтения (например, я считаю сколько денег на карте c1, начну перевод на c2 и в этот же момент владелец c1 снимет все деньги до 0)?

Что такое вложенный коннект?
С БД устанавливается соединение в рамках которого идёт работа. Если автокомит установлен, то каждый стейтмент будет работать в своей неявной транзакции.

Надеюсь, что можно что-то понять из псевдокода.

findByID имеет внутри Connection. В строчке if(findByID(from.getID()).getBalance.compareTo(amount)>=0)  он является вложенным по отношению к Connection выше

методы работают с разными соединениями никак не пересекаясь.. разве что пул отдаст одно и тоже соединение, поэтому его необходимо вернуть в состояние в котором взял из пула

В том, что пулл возвращает одно и то же соединение есть какие-то серьезные минусы?

(Или есть какая-то возможность избежать дублирования кода в данном примере?)

Нет, это его работа, держать все соединения и отдавать по требованию.

А если разные потоки будут использовать метод findByID, который получает Connection от пулла, отдающего один и тот же Connect? Разве не должен упасть с ошибкой?
(Да и Connection не выносят в поле DAO-класса, а используют в каждом методе свой)

У пула коннект не один, да и пулы пишутся так, что бы не отдавать занятое соединение

Но при этом, в данном случае, для исключения дублирования кода, пулл должен вернуть одно.. но оно ведь будет занято, получается.

методы работают с разными соединениями никак не пересекаясь.. разве что пул отдаст одно и тоже соединение, поэтому его необходимо вернуть в состояние в котором взял из пула

Зачем одно?

Соединение возвращается в пул при вызове метода close(), который вызывается сам в try-with-resources, потому что Connection имплементит Autoclosable