[
https://issues.apache.org/jira/browse/DERBY-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484300
]
Daniel John Debrunner commented on DERBY-2490:
----------------------------------------------
When running suites.All a few locations getTransactionExecute() is called when
the code is clearly dealing with the nested transaction (thus the caller is
using the wrong transaction object).
Some may not be a problem since:
- in one place it's error logging getting the transaction identifier
- in others it is getting the lock compatibility space to perform locking
and the nested and main transaction share the same lock space
One is performing a scan using the wrong transaction (to get a schema
descriptor)
Any api that requires the caller to be aware of which transaction method to
call is going to be subject to bugs like this, it would be much cleaner for the
LCC to only expose a single current transaction and switch internally as
required.
> 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.
