Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <469970.1175042612165.JavaMail.jira@brutus>
Date: Tue, 27 Mar 2007 17:43:32 -0700 (PDT)
From: "Daniel John Debrunner (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2490) Clarify transaction management in
 LanguageConnectionContext.
In-Reply-To: <9554213.1174953452141.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484664 ] 

Daniel John Debrunner commented on DERBY-2490:
----------------------------------------------

TransactionController.startNestedUserTransaction() actually has a good write-up on nested transactions.

One thing that is somewhat unclear is how many nested read-only transactions can exist.

The comments are clear that only 1 non-readOnly nested user transaction can exist, but not clear on the read-only case.

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