[
https://issues.apache.org/jira/browse/PHOENIX-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15019257#comment-15019257
]
James Taylor commented on PHOENIX-2431:
---------------------------------------
The implementation of this JIRA would create a hard dependency on transactions.
The reason to do this is for scaling: to allow our system table to grow beyond
a single region. We'd need to perf test this to prove that it doesn't present
any bottlenecks as part of this work. This wouldn't mandate that any user
tables are transactional, of course. I don't think we want to try to go down
the road of having the SYSTEM.CATALOG table be optionally transactional.
We've never considered making the deployment of the dependent Tephra jars
optional in maven (there are too many code dependencies), but until
transactions is declared GA, I think we need to make the running of the
transaction manager optional - I've filed PHOENIX-2441 for this.
If we go down the path of making transactions "pluggable", I think we can
revisit this though, IMHO.
> Make SYSTEM.CATALOG table transactional
> ---------------------------------------
>
> Key: PHOENIX-2431
> URL: https://issues.apache.org/jira/browse/PHOENIX-2431
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
>
> We currently update the SYSTEM.CATALOG table atomically by using the
> region.mutateRowsWithLocks() call. This works only if the mutations are all
> in the same region which can break down if enough views are created on a base
> table. Instead, now that we have transactions, we should change our
> SYSTEM.CATALOG table to transactional=true and stop using an endpoint
> coprocessor to update the table.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
