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

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

Github user sbroeder closed the pull request at:

    https://github.com/apache/incubator-trafodion/pull/713


> 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