[jira] Commented: (DERBY-2490) Clarify transaction management in LanguageConnectionContext.

["Daniel John Debrunner (JIRA)" <ji...@apache.org>]

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