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