[ISSUE] (TEPHRA-159) Optimize read-only client

[James Taylor (JIRA)]

James Taylor created an issue

Tephra / TEPHRA-159 Optimize read-only client Issue Type: Improvement Assignee: Poorna Chandra Created: 22/Dec/15 8:11 PM Priority: Major Reporter: James Taylor Allow a transaction client to declare itself as read-only to prevent the necessity of adding its transaction IDs to the in-flight transaction list. It's pretty typical that separate connections are used for reading and writing. Phoenix would leverage this when a connection is declared as read-only through standard JDBC Connection.setReadOnly(boolean) method. Add Comment

This message was sent by Atlassian JIRA (v6.1.5#6160-sha1:a61a0fc)

[James Taylor (JIRA)]

James Taylor updated an issue

Tephra / TEPHRA-159 Optimize read-only client

Change By: James Taylor Labels: phoenix

Add Comment

[James Taylor (JIRA)]

James Taylor commented on an issue

Re: Optimize read-only client It would be ideal if support for this could be added to TransactionContext through new or overloaded methods like startReadOnlyTx. Another advantage of providing this support is that the RPC done when the transaction is finished or aborted could be avoided - the transaction manager has no maintenance it needs to do for read-only transactions. I think this would get us most, if not all the way back to Phoenix performance without transactions for immutable tables (where we're seeing ~20% overhead).

Add Comment

Tephra / TEPHRA-159 Optimize read-only client

Allow a transaction client to declare itself as read-only to prevent the necessity of adding its transaction IDs to the in-flight transaction list. It's pretty typical that separate connections are used for reading and writing. Phoenix would leverage this when a connection is declared as read-only through standard JDBC Connection.setReadOnly(boolean) method.

[Andreas Neumann (JIRA)]

Andreas Neumann commented on an issue

Re: Optimize read-only client Read-only transactions sure deserve special treatment, and we can make use of the fact that they are known to have no change set, and they don't need to be in the exclude list. But we still need a way to tell Tephra that the transaction is finished. Otherwise, how can we guarantee that the (snapshot) versions of that transaction are not pruned before the transaction is done? One option would be to use a timeout, after which it is automatically removed.

Add Comment

[James Taylor (JIRA)]

James Taylor commented on an issue

Re: Optimize read-only client Good point, Andreas Neumann. Would it be possible to piggyback on the call that starts the next transaction and include the tx ID of the one that is now finished?

Add Comment

[Andreas Neumann (JIRA)]

Andreas Neumann commented on an issue

Re: Optimize read-only client That would be a nice optimization, James Taylor. It will help for use cases where it is guaranteed that there is a next transaction that is aware of the previous transaction id. Or we could time out the transaction if no next call happens within too long a time.

Add Comment

[James Taylor (JIRA)]

James Taylor commented on an issue

Re: Optimize read-only client Yes, +1. Piggyback on start of next transaction to end previous one plus a timeout after the tx timeout occurs.

Add Comment

[Terence Yim (JIRA)]

Terence Yim commented on an issue

Re: Optimize read-only client One addition advantage of having read-only client is that even the transaction is timed-out, we don't need to add it to invalid tx list.

Add Comment