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