Is one of the listener invocations going straight to the target object and one through the transactional proxy? Or are both going to the proxy?
I'm happy to consider more defensive handling there. However, please be aware that we only support cyclic dependencies in a lenient fashion, i.e. with various guarantees not applying. Our general recommendation certainly is to break the cyclic dependency, e.g. by factoring out a common delegate.
Is one of the listener invocations going straight to the target object and one through the transactional proxy? Or are both going to the proxy?
First case - "one going straight to the target object and one through the transactional proxy".
In org.springframework.context.event.AbstractApplicationEventMulticaster.ListenerRetriever#applicationListeners
I can see two subscriptions for one listener - straight & proxy
We're explicitly replacing a target ApplicationListener with its singleton proxy, if any: AbstractApplicationEventMulticaster checks this on registration through addApplicationListener now, where an existing listener object is given, whereas this cannot happen for registration by bean name in the first place.
Ilya Serkov opened SPR-15452 and commented
ApplicationEvent can be received by ApplicationListener two times.
Can be reproduced when these conditions coincide:
@Autowired
)@Transactional
methodAffects: 4.2.6
Referenced from: commits a2b3561, 9abf249
The text was updated successfully, but these errors were encountered: