[
https://issues.apache.org/jira/browse/PHOENIX-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15129635#comment-15129635
]
James Taylor commented on PHOENIX-2440:
---------------------------------------
Thanks, [~tdsilva]. Here's some feedback:
Add the Transaction section you removed from the Roadmap page to the New
Features page (i.e. recent.md).
For index.html, move the Transaction section before the Schema section. Also,
make it clear upfront that when enabling the transaction property (minor nit:
surround properties with <code></code> tags instead of double quotes), that
full ACID transactions are supported. Something like this (but feel free to
change):
Transactions
To enable full ACID transactions, a beta feature available in the 4.7.0
release, set the phoenix.transactions.enabled property to true. In this case,
you'll also need to run the transaction manager that's included in the
distribution. Once enabled, a table may optionally be declared as transactional
(see here for directions). Commits over transactional tables will have an
all-or-none behavior - either all data will be committed (including any updates
to secondary indexes) or none of it will (and an exception will be thrown).
Both cross table and cross row transactions are supported. In addition,
transactional tables will see their own uncommitted data when querying. An
optimistic concurrency model is used to detect row level conflicts with first
commit wins semantics. The later commit would produce an exception indicating
that a conflict was detected. A transaction is started implicitly when a
transactional table is references in a statement, at which point you will not
see updates from other connections until either a commit or rollback occurs.
Non transactional tables have no guarantees above and beyond the HBase
guarantee of row level atomicity[insert link here:
https://hbase.apache.org/acid-semantics.html]. In addition, non transactional
tables will not see their updates until after a commit has occurred. The DML
commands of Apache Phoenix, UPSERT VALUES, UPSERT SELECT and DELETE, batch
pending changes to HBase tables on the client side. The changes are sent to the
server when the transaction is committed and discarded when the transaction is
rolled back. If auto commit is turned on for a connection, then Phoenix will,
whenever possible, execute the entire DML command through a coprocessor on the
server-side, so performance will improve.
Timestamps [using smaller font like the subsections in the Schema section]
Most commonly, an application will let HBase manage timestamps. However, under
some circumstances, an application needs to control the timestamps itself. In
this case, a long-valued “CurrentSCN” property may be specified at connection
time to control timestamps for any DDL, DML, or query. This capability may be
used to run snapshot queries against prior row values, since Phoenix uses the
value of this connection property as the max timestamp of scans.
Timestamps may not be controlled for transactional tables. Instead, the
transaction manager assigns timestamps which become the HBase cell timestamps
after a commit. Timestamps still correspond to wall clock time, however they
are multiplied by 1,000,000 to ensure enough granularity for uniqueness across
the cluster.
> Document transactional behavior
> -------------------------------
>
> Key: PHOENIX-2440
> URL: https://issues.apache.org/jira/browse/PHOENIX-2440
> Project: Phoenix
> Issue Type: Task
> Reporter: James Taylor
> Assignee: Thomas D'Silva
> Labels: doc
> Attachments: index.html, roadmap.html, transactions.html
>
>
> We need to add a new top level page to explain transactions and their
> behavior from the user point of view:
> - How to configure a new/existing table to be transactional (CREATE TABLE and
> ALTER TABLE ... TRANSACTIONAL=true). Also that it's currently a one-way
> street - you cannot make a transactional table non transactional
> (PHOENIX-2439).
> - Transaction implicitly started when first statement run against a
> transactional table
> - Indexes on transactional table are transactional with data table.
> - Exception raised if transaction committed that conflicts (at row level)
> with other committed transaction.
> - Queries do not see commits of other transactions until transaction is ended
> (rolled back or committed).
> - Transaction will see their own updates (read-your-own-write behavior).
> - Requires that transaction manager is started (and how to start it).
> - Various configuration options specific to transactions
> - Invalid list - how it can potentially grow and how to manually clear it if
> necessary.
> - Unsupported behavior: for example, certain TTL behavior, no SCN.
> We also need to adjust existing web pages that currently says we don't
> support full ACID and promote this new capability.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
