
com.bigdata.btree.isolation.IConflictResolver Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of bigdata-core Show documentation
Show all versions of bigdata-core Show documentation
Blazegraph(TM) DB Core Platform. It contains all Blazegraph DB dependencies other than Blueprints.
/**
Copyright (C) SYSTAP, LLC DBA Blazegraph 2006-2016. All rights reserved.
Contact:
SYSTAP, LLC DBA Blazegraph
2501 Calvert ST NW #106
Washington, DC 20008
licenses@blazegraph.com
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; version 2 of the License.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
/*
* Created on Oct 23, 2006
*/
package com.bigdata.btree.isolation;
import java.io.Serializable;
import com.bigdata.btree.IIndex;
import com.bigdata.btree.ITuple;
import com.bigdata.journal.Journal;
import com.bigdata.journal.Tx;
/**
*
* 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.
*
*
* @see http://www.cs.brown.edu/~mph/Herlihy90a/p96-herlihy.pdf 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.
*
* @todo 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
* {@link Tx} object itself?
*
* @todo 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 {@link 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.
*
* @author Bryan Thompson
* @version $Id$
*/
public interface IConflictResolver extends Serializable {
/**
*
* Resolve a write-write conflict between a committed version on the journal
* and the current version within a transaction that is validating.
*
*
* @param writeSet
* The view on which conflict resolver must write the resolved
* index entry.
*
* @param txTuple
* The tuple written by the transaction that is being validated.
*
* @param currentTuple
* The current tuple committed in the global state with which the
* write-write conflict exists.
*
* @return true iff the conflict was resolved.
*/
public boolean resolveConflict(IIndex writeSet, ITuple txTuple,
ITuple currentTuple) throws Exception;
}