[
https://issues.apache.org/jira/browse/DERBY-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-2490:
----------------------------------
The best info for store provided nested info should be in the iapi javadoc
where you get the nested transaction, of all the store javadoc information the
most work in the past was put into the info located there: ie.
opensource/java/engine/org/apache/derby/iapi/store/access/TransactionController/startNestedUsetTransaction.
The store currently only supports 1 level of nesting. And Each user
transaction can only nest a single readonly transaction and a single separate
read/write transaction. The usage of these transactions that I am aware of are:
o read only nested transaction - used to get and release read locks on system
catalogs while compiling query. These locks
are compatible with
the parent transaction.
o read/write nested transaction - used to update system catalog and comit that
work separate and earlier than user transaction.
used to commit
updates to catalog which tracks system generated keys for auto generated
columns. locks in
this transaction are not compatible with parent transaction.
The store also supports one other internal transaction that is not exported
through the interface. This transaction is used to
implement "nested top transactions". These are low level data structure
changes which are committed separate from user transactions: btree split
operations, page allocation, .... There can only be one of these active at a
time also.
All 3 types can be actiive at the same time, but only 1 of each type.
> Clarify transaction management in LanguageConnectionContext.
> ------------------------------------------------------------
>
> Key: DERBY-2490
> URL: https://issues.apache.org/jira/browse/DERBY-2490
> Project: Derby
> Issue Type: Sub-task
> Components: SQL
> Reporter: Daniel John Debrunner
>
> LanguageConnectionContext has these four methods (as well as other
> commit/rollback methods) to manage transactions and specifically nested
> transactions.
> void beginNestedTransaction(boolean readOnly) throws StandardException;
> void commitNestedTransaction() throws StandardException;
> TransactionController getTransactionCompile();
> TransactionController getTransactionExecute();
> getTransactionCompile() returns the same as getTransactionExecute() if not in
> a nested transaction.
> nested transactions started out as "compile time" transactions but are now
> used at runtime, for example in permission lookup and identity columns(?),
> thus the name getTransactionCompile() can confuse readers.
> A cleaner api might be to just have a single getTransaction() method that
> returns the current transaction, which is main transaction (non-nested) except
> between calls to
> beginNestedTransaction()
> commitNestedTransaction()
> I think that is the logic today, one one transaction is active, either the
> nested one of the main one.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
