[
https://issues.apache.org/jira/browse/CAUSEWAY-3544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795685#comment-17795685
]
Daniel Keir Haywood edited comment on CAUSEWAY-3544 at 12/12/23 11:59 AM:
--------------------------------------------------------------------------
Post CAUSEWAY-3654, there is no longer any TransactionBoundaryAware interface,
we instead use Spring's own TransactionSynchronization. And it's also possible
to mark a bean with @TransactionalScope.
How does that relate to this ticket?
Well, the InteractionServiceDefault _is_ responsible for setting up a "default"
transaction, by calling TransactionServiceSpring#onOpen(...). And it commits
it afterwards in onClose(). The Command is 1:1 with the Interaction.
Moreover, within it there could be multiple transactions, for example if
transactionService#run(REQUIRES_NEW, ...) is used.
So what?
So, I think the remark in the description text: "I don't see any reason that
command publishing is any different from auditing," is incorrect. Why?
Because auditing (EntityPropertyChangeDefault) is transaction-scoped, and is
flushed with each transaction, whereas the command is associated with the
top-level default transaction.
Well, ok, so perhaps it isn't any different, it is transactionally-bound, just
with the transaction setup by InteractionService's call to
TransactionServiceSpring#onOpen (where the close tasks are held as attributes
of the Interaction) rather than those managed explicitly via
TranscationService#call.
However, the code in InteractionService currently captures any exception thrown
(eg by a CommandPublisher failing to persist changes); it's not clear how to
propagate this from a TransactionSynchronization implementation.
was (Author: danhaywood):
Post CAUSEWAY-3654, there is no longer any TransactionBoundaryAware interface,
we instead use Spring's own TransactionSynchronization. And it's also possible
to mark a bean with @TransactionalScope.
How does that relate to this ticket?
Well, the InteractionServiceDefault _is_ responsible for setting up a "default"
transaction, by calling TransactionServiceSpring#onOpen(...). And it commits
it afterwards in onClose(). The Command is 1:1 with the Interaction.
Moreover, within it there could be multiple transactions, for example if
transactionService#run(REQUIRES_NEW, ...) is used.
So what?
So, I think the remark in the description text: "I don't see any reason that
command publishing is any different from auditing," is incorrect. Why?
Because auditing (EntityPropertyChangeDefault) is transaction-scoped, and is
flushed with each transaction, whereas the command is associated with the
top-level default transaction.
Well, ok, so perhaps it isn't any different, it is transactionally-bound, just
with the transaction setup by InteractionService's call to
TransactionServiceSpring#onOpen (where the close tasks are held as attributes
of the Interaction) rather than those managed explicitly via
TranscationService#call.
> Refactor preInteractionClosed calling of completeAndPublishCommand, instead
> treat similar to audit trail publisher.
> -------------------------------------------------------------------------------------------------------------------
>
> Key: CAUSEWAY-3544
> URL: https://issues.apache.org/jira/browse/CAUSEWAY-3544
> Project: Causeway
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0.0-RC2
> Reporter: Daniel Keir Haywood
> Assignee: Daniel Keir Haywood
> Priority: Minor
> Fix For: 2.0.0-RC4
>
>
> In InteractionServiceDefault#preInteractionClosed() we currently call the
> `completeAndPublishCurrentCommand` first, and then later we loop around all
> transactionBoundaryAwareBeans callback, tell them to do their stuff. One of
> those is auditing (EntityChangePublishing).
> I don't see any reason that command publishing is any different from
> auditing, so I think we should refactor to use the same callbacks..
> Note that ExecutionPubilshing is not a transactionally aware aspect ... we
> publish that more eagerly, as each action invocation (or property edit) is
> executed .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
