BUG-8507: Fix replayed directCommit() on reconnect 87/57387/12
authorRobert Varga <robert.varga@pantheon.tech>
Thu, 18 May 2017 21:24:15 +0000 (23:24 +0200)
committerThanh Ha <thanh.ha@linuxfoundation.org>
Fri, 19 May 2017 17:41:16 +0000 (17:41 +0000)
commit59fab9a9bc6dbf9ad538b3df4460eff146c63ce2
tree751bd691e355850b98217a90229de64b3350c47f
parent90a377ec4fe7c1aa4df6d4fde74bfc8189e95b08
BUG-8507: Fix replayed directCommit() on reconnect

After remote shard reconnect of a brief isolation, we have observed
a NPE indicating that we encounter a NPE when faced with a direct
commit.

Assuming state engine correctness, this can happen during the time
when we have completed preCommit and before we have recorded the
request result (i.e. after commit completes).

At any rate, this flushes out the need for transaction transitions
to be idempotent, which is something ShardDataTreeTransaction and
ShardDataTreeCohort do not provide.

Encapsulate FrontendReadWriteTransaction state into distinct state
objects. This allows us to accurately track the internal transaction
state and detect when a canCommit, directCommit, preCommit and
doCommit are no-ops because the request is being already handled.

Change-Id: Ib533ec9a4882f51f7914c5b11865ac093c6d6ad0
Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
opendaylight/md-sal/sal-distributed-datastore/src/main/java/org/opendaylight/controller/cluster/datastore/FrontendReadWriteTransaction.java
opendaylight/md-sal/sal-distributed-datastore/src/test/java/org/opendaylight/controller/cluster/datastore/FrontendReadWriteTransactionTest.java [new file with mode: 0644]