Uploaded image for project: 'Isis'
  1. Isis
  2. ISIS-1361

View model that changes two domain objects only has one of them updated.

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.12.0
    • Fix Version/s: 1.12.1
    • Component/s: Core
    • Labels:
      None

      Description

      The relevant code being:

          @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;
          }
      

      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.

        Attachments

          Activity

            People

            • Assignee:
              danhaywood Dan Haywood
              Reporter:
              danhaywood Dan Haywood
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: