[
https://issues.apache.org/jira/browse/ISIS-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Haywood updated ISIS-1100:
------------------------------
Description:
The algorithm currently is to execute all queued PersistenceCommands
(corresponding to container.persist() or container.remove()) in order.
However, if the isis-module-audit module is configured, then, if an object
execute a transaction flush (as the result of obtaining a pre- value) this can
result in executing the same command all over.
In the particular case I investigated it resulted in double processing of a
delete command; on the second time around I got "cannot read from deleted
object" even though was ostensibly in the "preDelete" callback.
The required fix is a minor change to the way in which the command list are
queued to ensure that both (a) each command is executed precisely once while
(b) still allowing for additional commands to be added to the end of the
command list should that occur.
~~~~
There is also a very similar issue in the way in which the
changedObjectProperties are iterated over during preCommit; it's possible that
this collection might be added to while obtaining the post values of all
objects.
was:
The algorithm currently is to execute all queued PersistenceCommands
(corresponding to container.persist() or container.remove()) in order.
However, if the isis-module-audit module is configured, then, if an object
execute a transaction flush (as the result of obtaining a pre- value) this can
result in executing the same command all over.
In the particular case I investigated it resulted in double processing of a
delete command; on the second time around I got "cannot read from deleted
object" even though was ostensibly in the "preDelete" callback.
The required fix is a minor change to the way in which the command list are
queued to ensure that both (a) each command is executed precisely once while
(b) still allowing for additional commands to be added to the end of the
command list should that occur.
> Improve algorithm for flushing transaction and similarly in capturing post
> values (for auditing) on transaction preCommit
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: ISIS-1100
> URL: https://issues.apache.org/jira/browse/ISIS-1100
> Project: Isis
> Issue Type: Improvement
> Components: Core
> Affects Versions: core-1.8.0
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Priority: Minor
> Fix For: 1.9.0
>
>
> The algorithm currently is to execute all queued PersistenceCommands
> (corresponding to container.persist() or container.remove()) in order.
> However, if the isis-module-audit module is configured, then, if an object
> execute a transaction flush (as the result of obtaining a pre- value) this
> can result in executing the same command all over.
> In the particular case I investigated it resulted in double processing of a
> delete command; on the second time around I got "cannot read from deleted
> object" even though was ostensibly in the "preDelete" callback.
> The required fix is a minor change to the way in which the command list are
> queued to ensure that both (a) each command is executed precisely once while
> (b) still allowing for additional commands to be added to the end of the
> command list should that occur.
> ~~~~
> There is also a very similar issue in the way in which the
> changedObjectProperties are iterated over during preCommit; it's possible
> that this collection might be added to while obtaining the post values of all
> objects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
