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

У транзакции есть свойство Isolation, которое определяет видимость между транзакциями.

Но у меня возник вопрос, что увидит метод, который не помечен аннотацией @Transactional ?

увидят ли его изменения если это не read?

BlazkowiczЕсли у в контексте текущего потока не запущена транзакция, то все операции с БД происходят с автокоммитом. То есть на каждый запрос своя транзакция. Удивительно что вы пытаетесь вникнуть в такие дебри, но не пытаетесь понять как это вообще работает.

Можете обрисовать, что именно нужно понять?

BlazkowiczНужно понять как работает АОП, особенно в спринге.

Прокси, либо инструментация
BlazkowiczЧто происходит в начале транзакции, а что происходит в конце и как это связано с проксями через которые работает АОП.

я так понимаю, что обернули метод
begin transaction
наш метод
stop transaction
BlazkowiczThreadLocal

Я понимаю, что это, но как это связано с темой непонятно.
BlazkowiczНужно знать работу с транзакцией в JDBC API, так как в большинстве случаев другого и не нужно. Connection.setAutocommit() разве совсем не знакомый метод?
Все это можно за пару часов найти в исходниках Спрингa.
Если это всё увязать в одно целое, то исходного вопроса не возникло бы совсем.


Что-то в голову не пришло, что автокоммит это из Jdbc api.

Blazkowicz,

BlazkowiczВ Spring-е уже работает инструментация для транзакций? Круто.

А почему нет? для аннотации @Transactional.

BlazkowiczОбласть действия транзакции больше чем один метод.

Зависит же от propagation или я про другое ?

Blazkowicz,

Кажется мне нужно ещё разжевать/направить немножко(

не понятно.

Blazkowiczquestionerпропущено...

Зависит же от propagation или я про другое ?
ThreadLocal уже прочитан?




doThis и doThat полноценно участвуют в транзакции, но помечать их как @Transactional не нужно. Почему? Потому что информация о текущей транзакции у нас в ThreadLocal.

Да, это я понимаю. ThreadLocal подходит для хранения информации о транзакции.

Blazkowicz,

Непонятно почему @Transactional не может работать через инструментацию.

BlazkowiczquestionerПрокси, либо инструментация

В Spring-е уже работает инструментация для транзакций? Круто.


Я воспринял это так, что Вы считаете, что это очевидно неверно.

Я что-то не понимаю, наверное, но AOP в спринге может использоваться много для чего, например для кеширования. И как мы этот AOP сконфигурён так и будет spring работать. AspectJ часто ведь используют в ответах по реалихации AOP в spring.

Почему такие сомнения с @Transactional ?

Blazkowicz использование Spring AOP это не совсем одно и тоже что и использование других модулей Spring.

а что с ним не так?

Так Вы же сами в этом ответе в соседней теме писали, что если AOP реализован не через инструментацию, то могут быть проблемы с запуском транзакции при локальном вызове

http://www.sql.ru/forum/1244882/requiresnew?mid=20073053#20073053

BlazkowiczquestionerТак Вы же сами в этом ответе в соседней теме писали, что если AOP реализован не через инструментацию, то могут быть проблемы с запуском транзакции при локальном вызове
Это вообще к чему? Об этом и в мануале написано.

Когда Вы писали тот пост, то знали, что @Transactional не будет работать как надо если AOP реализован не через инструментацию, а тут как будто забыли.

Это с моей стороный так выглядит. Естественно Вы что-то иное имеете ввиду, но я не понимаю, что именно

BlazkowiczquestionerКогда Вы писали тот пост, то знали, что @Transactional не будет работать как надо если AOP реализован не через инструментацию, а тут как будто забыли.
У вас логические выводы нарушены. Во-первых нигде не говориться про "так надо". Во-вторых то что прокси не перехватывают вызовы методов внутри класса вообще никак не связано с тем работает ли декларативное управление транзакциями через compile time weaving или нет.
"не будет работать через прокси" не значит что "будет работать через инструментацию". Это значит что "будет работать через инструментацию, при услови что декларативное управление транзакциями умеет работать через инструментацию".
Беглый просмотр документации говорит что умеет. Но раньше, когда я интересовался этим вопросом, инструментация была геморроем. Поэтому я понятия не имел умеет так спринг или нет.

Хотелось бы докапаться до истины, почему нарушены причинно следственные связи) Я явно чего-то не понимаю.

Blazkowicz"не будет работать через прокси" не значит что "будет работать через инструментацию".
а как ещё? есть третий вариант?

Blazkowiczто что прокси не перехватывают вызовы методов внутри класса вообще никак не связано с тем работает ли декларативное управление транзакциями через compile time weaving или нет.

О,похоже загвоздка тут. А зачем вообще тогда прокся эта нужна если через нее @Transactional-ы/ @Autowired-ы работали?

с @Autowired я наверное погорячился

BlazkowiczquestionerХотелось бы докапаться до истины, почему нарушены причинно следственные связи) Я явно чего-то не понимаю.

Какой ещё истины? Походу вопросы закончились, осталось только "а поговорить?".

questionerа как ещё? есть третий вариант?

Предложение до конца дочитать не вариант?

questionerА зачем вообще тогда прокся эта нужна если через нее @Transactional-ы/ @Autowired-ы работали?
Не понял вопроса.

Да, с вопросом топика понятно.

Во время топика появилось непонимание про Spring AOP.

Почему раньше @Transactional раньше не мог работать через инструментацию?(это касалось только @Transactional ?)
Spring AOP может использоваться как собственно AOP, чтобы обрамлять свои методы какой-то своей логикой, а может, собственно для всяких @Transactional/@Cacheable.

Насколько я понимаю, AOP конфигурируется глобально.

Собственно если настроить AOP через инструментацию, то всё, что пользует AOP будет работать через инструментацию.

Blazkowicz Предложение до конца дочитать не вариант?
а что дочитать то?