[
https://issues.apache.org/jira/browse/PHOENIX-3623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907410#comment-15907410
]
Ohad Shacham edited comment on PHOENIX-3623 at 3/13/17 1:22 PM:
----------------------------------------------------------------
Hi [~giacomotaylor] and [~tdsilva]
Transaction starts from a state of read you own writes while checkpoint moves
the transaction to a stage of read only your writes that occur before the check
point.
Currently we implement only the checkpoint semantics. Aren't there scenarios
where "end of checkpoint" is needed? For example, where operations occurs after
an upsert that duplicates a table and we want that these operations will see
the upsert results? Does checkpoint forces every following operation to start
with a checkpoint?
I assume this is done by setVisiblity ?
Thx,
Ohad
was (Author: ohads):
Hi [~giacomotaylor] and [~tdsilva]
Transaction starts from a state of read you own writes while checkpoint moves
the transaction to a stage of read only your writes that occur before the check
point.
Currently we implement only the checkpoint semantics. Aren't there scenarios
where "end of checkpoint" is needed? For example, where operations occurs after
an upsert that duplicates a table and we want that these operations will see
the upsert results? Does checkpoint forces every following operation to start
with a checkpoint?
Thx,
Ohad
> Integrate Omid with Phoenix
> ---------------------------
>
> Key: PHOENIX-3623
> URL: https://issues.apache.org/jira/browse/PHOENIX-3623
> Project: Phoenix
> Issue Type: New Feature
> Reporter: Ohad Shacham
> Assignee: Ohad Shacham
>
> The purpose of this Jira is to propose a work plan for connecting Omid to
> Phoenix.
> Each task of the following will be handled in a seperate sub Jira. Subtasks
> 4.* are related to augmenting Omid to support features required by Phoenix
> and therefore, their corresponding Jiras will appear under Omid and not under
> Phoenix.
> Each task is completed by a commit.
> Task 1: Adding transaction abstraction layer (TAL) - Currently Tephra calls
> are integrated inside Phoenix code. Therefore, in order to support both Omid
> and Tephra, we need to add another abstraction layer that later-on will be
> connected to both Tephra and Omid. The first tasks is to define such an
> interface.
> Task 2: Implement TAL functionality for Tephra.
> Task 3: Refactor Phoenix to use TAL instead of direct calls to Tephra.
> Task 4: Implement Omid required features for Phoenix:
> Task 4.1: Add checkpoints to Omid. A checkpoint is a point in a transaction
> where every write occurs after the checkpoint is not visible by the
> transaction. Explanations for this feature can be seen in [TEPHRA-96].
> Task 4.2: Add an option to mark a key as non-conflicting. The motivation is
> to reduce the size of the write set needed by the transaction manager upon
> commit as well as reduce the conflict detection work.
> Task 4.3: Add support for transactions that never abort. Such transactions
> will only make other inflight transactions abort and will abort only in case
> of a transaction manager failure.
> These transactions are needed for ‘create index’ and the scenario was
> discussed in [TEPHRA-157] and [PHOENIX-2478]. Augmenting Omid with this kind
> of transactions was also discussed in [OMID-56].
> Task 4.4: Add support for returning multiple versions in a scan. The use case
> is described in [TEPHRA-134].
> Task 4.5: Change Omid's timestamp mechanism to return real time based
> timestamp, while keeping monotonicity.
> Task 5: Implement TAL functionality for Omid.
> Task 6: Implement performance tests and tune Omid for Phoenix use. This task
> requires understanding of common usage scenarios in Phoenix as well as
> defining the tradeoff between throughput and latency.
> Could you please review the proposed work plan?
> Also, could you please let me know whether I missed any augmentation needed
> for Omid in order to support Phoenix operations?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
