tephra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Neumann (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (TEPHRA-247) Avoid encoding the transaction multiple times
Date Thu, 11 Jan 2018 22:43:00 GMT

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

Andreas Neumann edited comment on TEPHRA-247 at 1/11/18 10:42 PM:
------------------------------------------------------------------

Hi Patrick, 
I like the idea of caching transaction objects in the coprocessor. However, the difficulty
is that the transaction may span multiple region servers. Every time we make a call to HBase,
we don't know whether we have sent the transaction to that region server before. The only
way to ensure that would be to send it to all regions of a table when the table enters the
transaction (in startTx), and similarly, at the end of the transaction, we would have to broadcast
the renoveFromCache to all regions. Still, I have a few doubts

- what happens on region split? The new region would not have the tx in the cache. 
- if the client crashes, will its transaction remain in the cache? We probably need to time
it out some how,
- is a transaction truly immutable? Checkpointing a transaction creates a new Transaction
object with the same transaction ID but a new write pointer. So I guess the key would have
to be the write pointer. 

Thoughts?


was (Author: anew):
Hi Patrick, 
I like the idea of caching transaction objects in the coprocessor. However, the difficulty
is that the transaction may span multiple region servers. Every time we make a call to HBase,
we don't know whether we have sent the transaction to that region server before. The only
way to ensure that would be to send it to all regions of a table when the table enters the
transaction (in startTx), and similarly, at the end of the transaction, we would have to broadcast
the renoveFromCache to all regions. Still, I have a few doubts

- what happens on region split? The new region would not have the tx in the cache. 
- is a transaction truly immutable? Checkpointing a transaction creates a new Transaction
object with the same transaction ID but a new write pointer. So I guess the key would have
to be the write pointer. 

Thoughts?

> Avoid encoding the transaction multiple times
> ---------------------------------------------
>
>                 Key: TEPHRA-247
>                 URL: https://issues.apache.org/jira/browse/TEPHRA-247
>             Project: Tephra
>          Issue Type: Improvement
>          Components: core, manager
>    Affects Versions: 0.12.0-incubating
>            Reporter: Andreas Neumann
>            Assignee: Andreas Neumann
>         Attachments: design.jpg
>
>
> Currently, the same transaction object is encoded again and again for every Get performed
in HBase. It would be better to cache the encoded transaction for the duration of the transaction
and reuse it, 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message