parent
0ded239453
commit
8de80ffe9e
|
@ -830,7 +830,7 @@ unhandled `InstrumentNotFoundException`.
|
||||||
</tx:advice>
|
</tx:advice>
|
||||||
----
|
----
|
||||||
|
|
||||||
When the Spring Framework's transaction infrastructure catches an exception and is
|
When the Spring Framework's transaction infrastructure catches an exception and it
|
||||||
consults configured rollback rules to determine whether to mark the transaction for
|
consults configured rollback rules to determine whether to mark the transaction for
|
||||||
rollback, the __strongest__ matching rule wins. So in the case of the following
|
rollback, the __strongest__ matching rule wins. So in the case of the following
|
||||||
configuration, any exception other than an `InstrumentNotFoundException` results in a
|
configuration, any exception other than an `InstrumentNotFoundException` results in a
|
||||||
|
@ -1936,9 +1936,9 @@ Registering a regular event listener is done via the `@EventListener` annotation
|
||||||
to bind it to the transaction use `@TransactionalEventListener`. When you do so, the listener
|
to bind it to the transaction use `@TransactionalEventListener`. When you do so, the listener
|
||||||
will be bound to the commit phase of the transaction by default.
|
will be bound to the commit phase of the transaction by default.
|
||||||
|
|
||||||
Let's take an example to illustrate this concept. Assume that a component publish an order
|
Let's take an example to illustrate this concept. Assume that a component publishes an order
|
||||||
created event and we want to define a listener that should only handle that event once the
|
created event and we want to define a listener that should only handle that event once the
|
||||||
transaction in which it has been published as committed successfully:
|
transaction in which it has been published has committed successfully:
|
||||||
|
|
||||||
[source,java,indent=0]
|
[source,java,indent=0]
|
||||||
[subs="verbatim,quotes"]
|
[subs="verbatim,quotes"]
|
||||||
|
@ -1953,8 +1953,8 @@ transaction in which it has been published as committed successfully:
|
||||||
}
|
}
|
||||||
----
|
----
|
||||||
|
|
||||||
The `TransactionalEventListener` annotation exposes a `phase` attribute that allows to customize
|
The `TransactionalEventListener` annotation exposes a `phase` attribute that allows us to customize
|
||||||
to which phase of the transaction the listener should be bound to. The valid phases are `BEFORE_COMMIT`,
|
which phase of the transaction the listener should be bound to. The valid phases are `BEFORE_COMMIT`,
|
||||||
`AFTER_COMMIT` (default), `AFTER_ROLLBACK` and `AFTER_COMPLETION` that aggregates the transaction
|
`AFTER_COMMIT` (default), `AFTER_ROLLBACK` and `AFTER_COMPLETION` that aggregates the transaction
|
||||||
completion (be it a commit or a rollback).
|
completion (be it a commit or a rollback).
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue