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] [Commented] (TEPHRA-99) Make "long running" transactions usable with TransactionContext
Date Mon, 18 Sep 2017 17:49:00 GMT

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

Andreas Neumann commented on TEPHRA-99:

Unfortunately, there is no easy way for a client to find out whether a previous transaction's
read snapshot is still consistent. I think this would be an excellent use case and motivation
for read-only transactions (TEPHRA-159).

By the way, this would be a good discussion to have on the dev@ mailing list.

> Make "long running" transactions usable with TransactionContext
> ---------------------------------------------------------------
>                 Key: TEPHRA-99
>                 URL: https://issues.apache.org/jira/browse/TEPHRA-99
>             Project: Tephra
>          Issue Type: Improvement
>          Components: core
>            Reporter: Gary Helmling
>            Assignee: Gary Helmling
> "Long running" transactions (type == LONG) are supported by the Tephra {{TransactionManager}},
but {{TransactionContext}} does not expose any way for clients to interact with them.  I think
this will require a couple changes:
> * add a {{startLong()}} method to TransactionContext
> * add a constructor to TransactionContext that takes an existing {{Transaction}} instance.
 Since long running transactions are often used in map reduce processing, the process committing
the transaction may be different from the process that started the transaction.  In this situation,
we need a way to pass the serialized transaction all the way through to the other process.
> Regarding map reduce support, we could use additional utilities or support in place to
make transactions easier to use with map reduce.  But this would at least serve as a first

This message was sent by Atlassian JIRA

View raw message