db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2490) Clarify transaction management in LanguageConnectionContext.
Date Wed, 28 Mar 2007 16:35:25 GMT

     [ 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.


Mime
View raw message