You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1, 2 and 3 involves 3rd party to initiate the flow. Such 3rd party can begin transaction before exercising any of the scenarios. So TX configuration could be easily done in Spring the conventional way (annotation Gateway interface with @Transactional) and the Thread would propagate the TX context until thread boundary breaks. The main thing is that all 3 of them expect TX to exist before they are initiated.
4, 5 and 6 does not involve human to initiate the flow, so it make sense to expose TX configuration (e.g., the same way we do it in poller now).
MessagingTemplate is really a helper class used by all of the above scenarios and based on the scenario transactional context might or might not exist. But in any event MessagingTemplate should not directly depend on spring-tx API.
Oleg Zhurakousky opened INT-1456 and commented
We have several ways of starting the message flow
1, 2 and 3 involves 3rd party to initiate the flow. Such 3rd party can begin transaction before exercising any of the scenarios. So TX configuration could be easily done in Spring the conventional way (annotation Gateway interface with
@Transactional
) and the Thread would propagate the TX context until thread boundary breaks. The main thing is that all 3 of them expect TX to exist before they are initiated.4, 5 and 6 does not involve human to initiate the flow, so it make sense to expose TX configuration (e.g., the same way we do it in poller now).
MessagingTemplate is really a helper class used by all of the above scenarios and based on the scenario transactional context might or might not exist. But in any event MessagingTemplate should not directly depend on spring-tx API.
Affects: 2.0 M7
This issue is a sub-task of #5369
The text was updated successfully, but these errors were encountered: