[
https://issues.apache.org/jira/browse/PHOENIX-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16731382#comment-16731382
]
James Taylor commented on PHOENIX-5084:
---------------------------------------
For consistency with the other metadata methods, change the rollback to a
commit. Also, there's one more method that could use the same logic:
{code:java}
@Override
public ResultSet getTableTypes() throws SQLException {
{code}
Though not strictly needed, it'd make the behavior consistent across all
metadata calls.
{quote}Won't that leave an aborted transaction around each time (which is
costly at least in Tephra)?
{quote}
For Tephra, a commit or rollback would be the same. They only become expensive
if the transaction manager cannot be reached (in which case they'd timeout and
end up on the invalid list).
I think this will fix the issue, but it's a bit unfortunate that the
PhoenixRuntime.getTableNoCache call calls MetaDataClient.updateCache (which
starts a transaction). Since we're explicitly saying we want to bypass the
cache, then it seems like we could not start the transaction but just use
LATEST_TIMESTAMP. Something to think about, [~tdsilva]. Also, I thought we were
actually calling PhoenixRuntime.getTable and relying the cache to prevent RPCs.
Separate from this issue (in a new JIRA), I'd recommend thinking through the
behavior when
# auto commit is off. Do we want sqlline to be inadvertently starting a
transaction and leaving it open?
# DML operations are mixed with metadata calls. What if we had something like
this?
{code:java}
UPSERT VALUES
connection.getMetaData().getTables(...)
connection.rollback(){code}
In this case, the upserted values would get committed before the rollback
occurred. There's a similar issue with issuing DDL on the same connection with
uncommitted data. In that case, we issue a rollback before we start executing
the DDL.
IMO, we should either:
# Recommend to users to not mix metadata data operations with DML and we
should follow the same approach as we do with DDL - execute a rollback prior to
starting the operation and execute another rollback at the end (so we don't
inadvertently start a transaction and leave it open when auto commit if off).
# Or alternately, fix the PhoenixRuntime.getTableNoCache to not start a
transaction. Since we're explicitly saying we want to bypass the cache, then it
seems like we should not start the transaction but just use LATEST_TIMESTAMP.
Something to think about, [~tdsilva]. However, I'm not sure why we're not using
PhoenixRuntime.getTable instead and relying on the cache, though - we could
save a lot of RPCs that way. If we could use that *and* not start a
transaction, that'd be ideal, but I think we need to start a transaction to get
back a timestamp from the transaction manager that we can use in the cache (for
consistency across queries/DML).
> Changes from Transactional Tables are not visible to query in different client
> ------------------------------------------------------------------------------
>
> Key: PHOENIX-5084
> URL: https://issues.apache.org/jira/browse/PHOENIX-5084
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.15.0, 4.14.1
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Priority: Blocker
> Attachments: PHOENIX-5084-v2.txt, PHOENIX-5084.txt
>
>
> Scenario:
> # Upsert and commit some data into a transactional table. (Autocommit or
> following by explicit commit)
> # Query same table from another client
> The first query on the other client will not see the newly upserted/committed
> data (regardless of how long one waits).
> A second identical query will see the new data.
> This happens with both Omid and Tephra.
> I guess we can't write a test for this, since it requires multiple JVMs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
