db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2490) Clarify transaction management in LanguageConnectionContext.
Date Tue, 27 Mar 2007 23:03:32 GMT

    [ 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

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

View raw message