Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <9237849.1175036612839.JavaMail.jira@brutus>
Date: Tue, 27 Mar 2007 16:03: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_12484639 ] 

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

The beginNestedTransaction() and commitNestedTransaction() api/implementation is confusing. Here's a list of some of the items I've found so far ...

If beginNestedTransaction() is called but commitNestedTransaction() not called then the nested transaction will not be destroyed. Some callers avoid this by having the commitNestedTransaction() in a finally block, but this will mean commit is called even if an exception was thrown. This may not be a problem with the current code as the 'readOnly' flag to beginNestedTransaction() is always set to true. It would be good to either document the requirement for a finally block or ensure the rollback path cleans up the nested transaction.

However one caller to beginNestedTransaction(true) (read-only) has comments indicating that writes can occur (EmbedDatabaseMetaData.prepareSPS()).

beginNestedTransaction() has a boolean for readOnly but it reuses the current nested transaction regardless of the previous setting of this flag, thus with the current api one could have a request for a read/write transaction return a read-only transaction. (same comments as above apply for all callers indicating read-only).

Callers in the language area that require a read-write nested transaction don't use this api and instead use the lower-level api on TransactionController, ie.
  getTransactionExecute().startNestedUserTransaction(false). Thus some confusion here, when does a caller use the LCC method and when the store method? Again the api seems to require a finally block to clean things up and a commit is always performed, even on exception.

I think a commit is always performed on a nested transaction as comments somewhere (in store I think) indicated that rolling back a nested transaction will rollback the parent as well.

Unclear if the model supported is endless nesting, e.g. can I call startNestedUserTransaction() on a nested transaction. I think not from the implementation, it seems maybe nesting is only one level deep, but one can have a nested read only transaction and a nested read/write transaction active.


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