[
https://issues.apache.org/jira/browse/DERBY-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919273#action_12919273
]
Kristian Waagan commented on DERBY-4822:
----------------------------------------
I don't think this is about efficiency, but about correctness for a few special
cases - where a nested transaction has been created.
Derby might get into trouble if some of the work is performed using a nested
transaction and some by the parent/main transaction. The nested transaction was
introduced to be able to commit some work immediately without committing the
work done by the parent transaction, or to release locks as early as possible
where appropriate. I.e. typically do work with parent tx, do some (short
duration) special work with nested tx, commit nested tx, continue with work
using the parent tx.
In terms of code, the difference boils down to the following:
return tran;
vs
return (readOnlyNestedTransaction != null) ? readOnlyNestedTransaction
: tran;
In a scenario as mentioned above, it is important that the correct transaction
is being used at all times.
>From what I know about this issue, the patch looks correct - I'm +1 to commit
>it.
I will wait for a few more days to see if anyone with more knowledge about this
pitches in.
> [patch] DropSchemaConstantAction: could reuse the current connection provided
> by the available activation object
> ----------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4822
> URL: https://issues.apache.org/jira/browse/DERBY-4822
> Project: Derby
> Issue Type: Improvement
> Components: Network Server
> Reporter: Martin Monperrus
> Priority: Minor
> Attachments: patch.txt
>
>
> In DropSchemaConstantAction.executeConstantAction, getSchemaDescriptor is
> called with a null parameter. Instead, one could reuse the current
> transaction controller directly available with
> "activation.getLanguageConnectionContext().getTransactionExecute()" as it's
> done with other subclasses of DDLConstantAction.
> Regards, --Martin
> Index:
> java/engine/org/apache/derby/impl/sql/execute/DropSchemaConstantAction.java
> ===================================================================
> ---
> java/engine/org/apache/derby/impl/sql/execute/DropSchemaConstantAction.java
> (revision 1001658)
> +++
> java/engine/org/apache/derby/impl/sql/execute/DropSchemaConstantAction.java
> (working copy)
> @@ -27,6 +27,7 @@
> import org.apache.derby.iapi.sql.dictionary.DataDictionary;
> import org.apache.derby.iapi.sql.dictionary.SchemaDescriptor;
> import org.apache.derby.iapi.sql.execute.ConstantAction;
> +import org.apache.derby.iapi.store.access.TransactionController;
>
> /**
> * This class describes actions that are ALWAYS performed for a
> @@ -82,6 +83,7 @@
> {
> LanguageConnectionContext lcc =
> activation.getLanguageConnectionContext();
> DataDictionary dd = lcc.getDataDictionary();
> + TransactionController tc = lcc.getTransactionExecute();
>
> /*
> ** Inform the data dictionary that we are about to write to
> it.
> @@ -94,7 +96,7 @@
> */
> dd.startWriting(lcc);
>
> - SchemaDescriptor sd = dd.getSchemaDescriptor(schemaName, null, true);
> + SchemaDescriptor sd = dd.getSchemaDescriptor(schemaName, tc, true);
>
> sd.drop(lcc, activation);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
