[dna-issues] [JBoss JIRA] Commented: (DNA-583) The In-Memory connector.execute(...) method is not 'all-or-nothing'

[Randall Hauch (JIRA)]

    [ https://jira.jboss.org/jira/browse/DNA-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12499594#action_12499594 ] 

Randall Hauch commented on DNA-583:
-----------------------------------

Added a mechanism by which the InMemory connector maintains the original state of nodes the first time they are changed, so that the original state can be restored should the changes be rolled back.  This does add a little extra overhead as nodes are changed, but there's almost no extra overhead to committing the changes (since the original states are thrown out).  When a rollback does occur, there is (obviously) some extra work restoring the state of the changed nodes.

There is also a new TransactionalConnectorTest abstract class in the 'org.jboss.dna.graph.connector.test' package that can be subclassed to create a connector-specific test to verify that a rollback results in no changes to the state.  A new InMemoryConnectorTransactionalTest concrete class was created to test the InMemory connector.

This design was a tradeoff that achieves simplicity and straightforwardness (and encapsulation within the InMemoryRepositorySource code) while adding only modest overhead to the changes.  It is possible that the design could be improved to lower the overhead of each change, but this change does only add less than 1-2% overhead the 'dna-jcr' unit tests (<0.9sec increase on 59 sec tests, which is actually within the variation common between runs).

> The In-Memory connector.execute(...) method is not 'all-or-nothing'
> -------------------------------------------------------------------
>
>                 Key: DNA-583
>                 URL: https://jira.jboss.org/jira/browse/DNA-583
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Connectors
>    Affects Versions: 0.7
>            Reporter: Randall Hauch
>            Priority: Blocker
>             Fix For: 1.0
>
>
> Maybe the easiest way to correct this is to record the MapNode objects before they are changed, and then if a rollback occurs, to replace the newly-changed MapNode objects with the original.  This is a bit more complicated, since individual MapNode methods are called to change the node.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira