[jira] [Resolved] (ISIS-1361) View model that changes two domain objects only has one of them updated.

["Dan Haywood (JIRA)" <ji...@apache.org>]

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

Dan Haywood resolved ISIS-1361.
-------------------------------
    Resolution: Fixed

> View model that changes two domain objects only has one of them updated.
> ------------------------------------------------------------------------
>
>                 Key: ISIS-1361
>                 URL: https://issues.apache.org/jira/browse/ISIS-1361
>             Project: Isis
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.12.0
>            Reporter: Dan Haywood
>            Assignee: Dan Haywood
>            Priority: Minor
>             Fix For: 1.12.1
>
>
> The relevant code being:
> {code}
>     @Action
>     public Compare2 swap() {
>         final Colour leftFavoriteColour = getLeftFavoriteColour();
>         final Boolean leftFlag = getLeftFlag();
>         final Colour rightFavoriteColour = getRightFavoriteColour();
>         final Boolean rightFlag = getRightFlag();
>         final SimpleObject left = getLeft();
>         final SimpleObject right = getRight();
>         left.setFavoriteColour(rightFavoriteColour);
>         left.setFlag(rightFlag);
>         right.setFavoriteColour(leftFavoriteColour);
>         right.setFlag(leftFlag);
>         transactionService.flushTransaction();
>         return this;
>     }
> {code}
> I'm seeing that the first object modified ("left") is updated, but the second is not.
> Tracing through the Isis and JDO code, it seems that the left object is dirtied, and then this is flushed when the right object is subsequently modified, because - by default - JDO will flush a first object once a second object starts to be modified; see http://www.datanucleus.org/products/datanucleus/jdo/transactions.html and "datanucleus.datastoreTransactionFlushLimit" property; to whit: "represents the number of dirty objects before a flush is performed. This defaults to 1"
> So the action finishes with the "right" object still dirtied, so far as JDO is concerned, but not yet flushed.
> The reason that JDO doesn't flush is that  the new auto-clone functionality for JAXB view models means that we end up creating a new view model, and this new view model causes the PersistentEntityAdapter.class that in turn calls BookmarkService#lookup, which in turn calls Isis' PersistenceSession and finally JDO's PersistenceManager#refresh(...).  This ends up trampling over the state of the "right" domain object.
> The fix is to extend BookmarkService's API to provide an option as to whether to overwrite or to merely lookup an object.  To avoid breakage with existing applications that might rely on the current behaviour, the default will be to overwrite.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)