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 04:42:32 GMT

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