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)