db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2490) Clarify transaction management in LanguageConnectionContext.
Date Thu, 29 Mar 2007 16:39:25 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mike Matrigali updated DERBY-2490:

yes, store enforces read only for a read only transaction.  

The implementing code can be seen in Xact.java.  The allowed state of the transaction is maintained
by the private readOnly variable.  The state of the transaction can be:
protected static final int  CLOSED          = 0;
protected static final int  IDLE            = 1;
protected static final int  ACTIVE          = 2;
protected static final int  UPDATE          = 3;
protected static final int  PREPARED        = 4;

setUpdateState() is called whenever an update (as tracked by the system requesting to log
something) is called on a transaction that is not yet in UPDATE state.  If that call is made
on a read only transaction a protocol error is raised.

> 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