hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eugene Koifman (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HIVE-12421) Streaming API add TransactionBatch.beginNextTransaction(long timeout)
Date Mon, 01 May 2017 19:24:04 GMT

     [ https://issues.apache.org/jira/browse/HIVE-12421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Eugene Koifman updated HIVE-12421:
----------------------------------
    Description: 
TransactionBatchImpl.beginNextTransactionImpl() has

{noformat}
        LockResponse res = msClient.lock(lockRequest);
        if (res.getState() != LockState.ACQUIRED) {
          throw new TransactionError("Unable to acquire lock on " + endPt);
        }
{noformat}

This means that if there are any competing locks already taken, this will throw an Exception
to client.  This doesn't seem like the right behavior.  It should block.

We could also add TransactionBatch.beginNextTransaction(long timeoutMs) to  give the client
more control.

cc [~alangates]  [~sriharsha]

  was:
TransactionBatchImpl.beginNextTransactionImpl() has

{noformat}
        LockResponse res = msClient.lock(lockRequest);
        if (res.getState() != LockState.ACQUIRED) {
          throw new TransactionError("Unable to acquire lock on " + endPt);
        }
{noformat}

This means that if there are any competing locks already take, this will throw an Exception
to client.  This doesn't seem like the right behavior.  It should block.

We could also add TransactionBatch.beginNextTransaction(long timeoutMs) to  give the client
more control.

cc [~alangates]  [~sriharsha]


> Streaming API add TransactionBatch.beginNextTransaction(long timeout)
> ---------------------------------------------------------------------
>
>                 Key: HIVE-12421
>                 URL: https://issues.apache.org/jira/browse/HIVE-12421
>             Project: Hive
>          Issue Type: Improvement
>          Components: HCatalog, Transactions
>    Affects Versions: 0.14.0
>            Reporter: Eugene Koifman
>            Assignee: Eugene Koifman
>            Priority: Critical
>
> TransactionBatchImpl.beginNextTransactionImpl() has
> {noformat}
>         LockResponse res = msClient.lock(lockRequest);
>         if (res.getState() != LockState.ACQUIRED) {
>           throw new TransactionError("Unable to acquire lock on " + endPt);
>         }
> {noformat}
> This means that if there are any competing locks already taken, this will throw an Exception
to client.  This doesn't seem like the right behavior.  It should block.
> We could also add TransactionBatch.beginNextTransaction(long timeoutMs) to  give the
client more control.
> cc [~alangates]  [~sriharsha]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message