You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by "Dan Haywood (JIRA)" <ji...@apache.org> on 2015/06/17 02:37:00 UTC

[jira] [Updated] (ISIS-1100) Improve algorithm for flushing transaction and similarly in capturing post values (for auditing) on transaction preCommit

     [ https://issues.apache.org/jira/browse/ISIS-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dan Haywood updated ISIS-1100:
------------------------------
    Fix Version/s:     (was: 1.10.0)
                   1.9.0

> 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)