com.bigdata.btree.isolation
Interface IConflictResolver

All Superinterfaces:

Serializable

All Known Implementing Classes:

NoConflictResolver

public interface IConflictResolver
extends Serializable

An interface invoked during backward validation when a write-write conflict has been detected. The implementation must either resolve the write-write conflict by returning a new version in which the conflict is resolved or report an unresolvable conflict, in which case backward validation will force the transaction to abort.

Version:

$Id: IConflictResolver.java 2265 2009-10-26 12:51:06Z thompsonbry $

Author:

Bryan Thompson

See Also:

for an excellent discussion of data type specific state-based conflict resolution, including examples for things such as bank accounts.

TODO:

Write tests in which we do state-based conflict resolution for both the bank account examples in Herlihy and the examples that we will find in race conditions for the lexical terms and statements in an RDF model., How to handle cascading dependencies. For example, if there is a write-write conflict on the terms index of an RDF store then the reverse index and any statements written in the transaction for the term with which the write-write conflict exists must also be updated. This will require lots of application knowledge and access to the Tx object itself?, The burden of deserialization is on the application and its implementation of this interface at present. Will object deserialization be buffered by a cache? Cache integrity is tricky here since the objects being reconciled belong to different transactional states. I can see a situation in which conflict resolution requires multiple changes in a graph structure, and could require simultaneous traversal of both a read-only view of the last committed state on the journal and a read-write view of the transaction. Resolution would then proceed by WRITE or DELETE operations on the transaction. The method signature would be changed to: This would have to allow READ,WRITE,and DELETE operations during PREPARE.
Handling distributed conflicts could also require awareness of the int64 identifier. That is accessible to the caller if they have saved a reference to the Journal in the constructor. Such resolution would have to be network aware (i.e., aware that there was a distributed database).
If we change to allowing object graph traversals during conflict resolution, then we need to closely consider whether cycles can form and how they will ground out.

Method Summary

boolean

resolveConflict(IIndex writeSet, ITuple txTuple, ITuple currentTuple) Resolve a write-write conflict between a committed version on the journal and the current version within a transaction that is validating.

Method Detail

resolveConflict

boolean resolveConflict(IIndex writeSet,
                        ITuple txTuple,
                        ITuple currentTuple)
                        throws Exception

Resolve a write-write conflict between a committed version on the journal and the current version within a transaction that is validating.

Parameters:

writeSet - The view on which conflict resolver must write the resolved index entry.

txTuple - The tuple written by the transaction that is being validated.

currentTuple - The current tuple committed in the global state with which the write-write conflict exists.

Returns:

true iff the conflict was resolved.

Throws:

Exception