тебя спасло только, что в сервисе над update висит обычный не readonly transactional. Отсюда вопрос, зачем над getTagById висит readonly, если можно сразу над сервисом разруливать транзакцию
транзакций врядли 2 откроется, если не переопределять propagation, но думаю, лучше просто использовать @Transactional(readOnly = true) над сервисами для get, а не над репозиториями, потому что если эти методы репозиториев будут переиспользовать для update методов, то сущность не проапдейтится
В greenplum 6й версии стоит пг 9.6. Не знаю, можно ли на него накатить этот плагин, скорее всего можно
у тебя есть метод с readonly, возвращающий сущность
Optional<Tag> getTagById(long id);https://github.com/isdn/records-dto/blob/01c1cd4c298499f250cb2b7113d91745ad47c6bf/src/main/java/dev/isdn/demo/records_dto/app/domain/tag/TagRepository.java#L28 и ты его используешь только в update https://github.com/isdn/records-dto/blob/01c1cd4c298499f250cb2b7113d91745ad47c6bf/src/main/java/dev/isdn/demo/records_dto/app/domain/tag/TagService.java#L43При readonly dirty-check не должен работать https://vladmihalcea.com/spring-read-only-transaction-hibernate-optimization/
тебя спасло только, что в сервисе над update висит обычный не readonly transactional. Отсюда вопрос, зачем над
getTagById висит readonly, если можно сразу над сервисом разруливать транзакциютранзакций врядли 2 откроется, если не переопределять propagation, но думаю, лучше просто использовать @Transactional(readOnly = true) над сервисами для get, а не над репозиториями, потому что если эти методы репозиториев будут переиспользовать для update методов, то сущность не проапдейтится