[ 
https://issues.apache.org/jira/browse/TRAFODION-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15511098#comment-15511098
 ] 

ASF GitHub Bot commented on TRAFODION-1435:
-------------------------------------------

Github user DaveBirdsall commented on a diff in the pull request:

    https://github.com/apache/incubator-trafodion/pull/713#discussion_r79925019
  
    --- Diff: 
core/sqf/src/seatrans/hbase-trx/src/main/java/org/apache/hadoop/hbase/coprocessor/transactional/SsccRegionEndpoint.java.tmpl
 ---
    @@ -2283,6 +2578,110 @@ CoprocessorService, Coprocessor {
     
        }
     
    +  public void checkAndDeleteRegionTx(RpcController controller,
    +                          SsccCheckAndDeleteRegionTxRequest request,
    +                          RpcCallback<SsccCheckAndDeleteRegionTxResponse> 
done) {
    +/*
    +    SsccCheckAndDeleteRegionTxResponse response = 
SsccCheckAndDeleteRegionTxResponse.getDefaultInstance();
    +
    +    byte [] rowArray = null;
    +    com.google.protobuf.ByteString row = null;
    +    com.google.protobuf.ByteString family = null;
    +    com.google.protobuf.ByteString qualifier = null;
    +    com.google.protobuf.ByteString value = null;
    +    MutationProto proto = request.getDelete();
    +    MutationType type = proto.getMutateType();
    +    Delete delete = null;
    +    Throwable t = null;
    +    WrongRegionException wre = null;
    +    int status = 0;
    +    boolean result = false;
    +    long tid = request.getTid();
    +    long startId = request.getStartId();
    +    boolean autoCommit = request.getAutoCommit();
    +
    +    java.lang.String name = ((com.google.protobuf.ByteString) 
request.getRegionName()).toStringUtf8();
    +
    +    
org.apache.hadoop.hbase.coprocessor.transactional.generated.SsccRegionProtos.SsccCheckAndDeleteRegionTxResponse.Builder
 checkAndDeleteRegionTxResponseBuilder = 
SsccCheckAndDeleteRegionTxResponse.newBuilder();
    +
    +    if (wre == null && type == MutationType.DELETE && proto.hasRow())
    +    {
    +      rowArray = proto.getRow().toByteArray();
    +
    +      try {
    +         delete = ProtobufUtil.toDelete(proto);
    +      } catch (Throwable e) {
    +         if (LOG.isTraceEnabled()) LOG.trace("checkAndDeleteRegionTx 
caught exception ", e);
    +         t = e;
    +      }
    +
    +      // Process in local memory
    +      if (delete != null && t == null)
    +      {
    +        if (request.hasRow()) {
    +          row = request.getRow();
    +
    +          if (!Bytes.equals(rowArray, request.getRow().toByteArray()))
    +            t = new 
org.apache.hadoop.hbase.DoNotRetryIOException("Action's " +
    +                 "Delete row must match the passed row");
    +        }
    +
    +        if (t == null) {
    --- End diff --
    
    I know this code is presently commented out (and so, presumably a work in 
progress), but I'm confused by the logic that extracts the row etc. then 
doesn't do anything more with it. Is this just saving these values in the 
members of the object? If so, why do we not care about their previous state?


> SQL operations not always performed transactionally with AUTOCOMMIT OFF
> -----------------------------------------------------------------------
>
>                 Key: TRAFODION-1435
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-1435
>             Project: Apache Trafodion
>          Issue Type: Improvement
>          Components: dtm
>    Affects Versions: 0.6 (pre-incubation)
>            Reporter: Sean Broeder
>            Assignee: Sean Broeder
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> For single region, single row operations (both IDU DML as well as select) SQL 
> will avoid beginning a transaction and perform the operation directly in 
> HBase.
> The feeling was that for single row operations a trasnaction was not 
> necessary as HBase would make the operation atomic and provide the necessary 
> guarantees.  The problem is this circumvents the endpoint coprocessor and 
> makes conflict detection with other concurrent transactions impossible.
> For performance reasons we should try to approximate the autocommit behavior 
> as much as possible while preserving the conflict detection.  We can achieve 
> this by implementing 'region transactions' whereby the region will create its 
> own transaction identifier when a nontransactional operation arrives in the 
> coprocessor.  We will need to override all HTable nontransactional operations 
> in both the TransactionalTable and SsccTransactionalTable classes.  The 
> override will create a new transaction identifier specific to the region 
> transaction and then use that for all modifications as if it were issued by 
> the DTM.
> The transaction identifier needs to be unique so that other threads 
> performing similar operations do not get confused at conflict resolution 
> time.  One possibility is to maintain an AtomicLong in the region that can be 
> incremented whenever such a transaction is needed.  This keeps all processing 
> inside the region and eliminates any RPC to another server process.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to