[
https://issues.apache.org/jira/browse/ISIS-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14523128#comment-14523128
]
ASF subversion and git services commented on ISIS-1142:
-------------------------------------------------------
Commit 30e9e10d8cca86bffaf60d56ced0475b97655994 in isis's branch
refs/heads/master from [~danhaywood]
[ https://git-wip-us.apache.org/repos/asf?p=isis.git;h=30e9e10 ]
ISIS-1142: guard in FrameworkSynchronizer
> FrameworkSynchronizer should handle case of adapter already marked as
> destroyed
> -------------------------------------------------------------------------------
>
> Key: ISIS-1142
> URL: https://issues.apache.org/jira/browse/ISIS-1142
> Project: Isis
> Issue Type: Bug
> Components: Core
> Affects Versions: core-1.8.0
> Reporter: Dan Haywood
> Assignee: Dan Haywood
> Priority: Minor
> Fix For: 1.9.0
>
>
> The FrameworkSynchronizer aims to keep Isis' internal ResolveState in sync
> with the actual persistence state of the pojos. (One day we'll get rid of
> all this, just not yet).
> In the meantime, in the postLoad callback, it's possible that the adapter has
> already been marked as destroyed, eg:
> - the object was deleted in an action (ie queued a DestroyCommand
> - subscriber on the action performed a post-execute which ran a query
> - running the query flushed the command, causing the pojo to be deleted and
> its adapter to be set to destroyed
> - in the commit, DN's clean up of query results causes pending pojos in
> result set to be resolved, triggering the postLoad callback method for a pojo
> that was deleted
> We should therefore guard for the situation that the adapter is already set
> to be Destroyed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
