Dan Haywood created ISIS-1361:
---------------------------------

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

Reply via email to