[
https://issues.apache.org/jira/browse/DERBY-4731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-4731:
----------------------------------
Attachment: derby_4731.diff
This patch does the work of temp table cleanup on commit during an XA commit in
a nested updatable user transaction. I believe it is ok to do this in a nested
transaction
for XA because it does the right thing in both possible cases:
1) If the XA transaction commits successfully then the same work has been done.
Because of where it is done in the code, the committing user can never get
access
to the global temp tables between the time the nested xact commits and the
XA
transaction commits.
2) If the XA transaction fails to commit somehow, then I think one of two
things will happen:
a) the session will go away, and then it does not matter what happens to
the session
life objects.
b) the transaction will rollback, and on commit work which deleted the rows
is the
same work that needs to get done on rollback.
The only locks the nested transaction gets is created new containers, so there
should
be no problem with lock contention of the work with either the parent
transaction, or
any other transactions.
It fixes the xtestXATempTableD4731_RawStore()
fixture, but does not fix the xtestXATempTableD4731_Assert.
It also passes full set of tests.
I have not debugged the xtestXATempTableD4731_Assert case.
> XA two phase commit with active GLOBAL TEMPORARY TABLE causes An internal
> error identified by RawStore module
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4731
> URL: https://issues.apache.org/jira/browse/DERBY-4731
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.1.0, 10.7.0.0
> Reporter: Kathey Marsden
> Assignee: Mike Matrigali
> Attachments: derby_4731.diff, ReproXATempTable.java,
> ReproXATempTableAssert.java, utilXid.java
>
>
> If an XA two phase commit is performed while an GLOBAL TEMPORARY TABLE is
> active, it will fail with:
> XAER_RMERR
> Exception in thread "main" javax.transaction.xa.XAException: An internal
> error w
> as identified by RawStore module.
> at
> org.apache.derby.jdbc.EmbedXAResource.wrapInXAException(EmbedXAResour
> ce.java:820)
> at
> org.apache.derby.jdbc.EmbedXAResource.commit(EmbedXAResource.java:143
> )
> at ReproXATempTable.tempTableInXA(ReproXATempTable.java:51)
> at ReproXATempTable.main(ReproXATempTable.java:14)
> Caused by: java.sql.SQLTransactionRollbackException: An internal error was
> ident
> ified by RawStore module.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLE
> xceptionFactory40.java:88)
> at
> org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:256)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException
> (TransactionResourceImpl.java:391)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Tr
> ansactionResourceImpl.java:346)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConne
> ction.java:2269)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.xa_commit(EmbedConnection.
> java:2924)
> at
> org.apache.derby.jdbc.XATransactionState.xa_commit(XATransactionState
> .java:339)
> at
> org.apache.derby.jdbc.EmbedXAResource.commit(EmbedXAResource.java:141
> )
> ... 2 more
> Caused by: java.sql.SQLException: An internal error was identified by
> RawStore m
> odule.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExc
> eptionFactory.java:45)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransport
> AcrossDRDA(SQLExceptionFactory40.java:119)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLE
> xceptionFactory40.java:70)
> ... 9 more
> Caused by: ERROR 40XT0: An internal error was identified by RawStore module.
> at
> org.apache.derby.iapi.error.StandardException.newException(StandardEx
> ception.java:276)
> at
> org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java:18
> 09)
> at
> org.apache.derby.impl.store.raw.xact.Xact.addContainer(Xact.java:1357
> )
> at org.apache.derby.impl.store.access.heap.Heap.create(Heap.java:274)
> at
> org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.creat
> eConglomerate(HeapConglomerateFactory.java:195)
> at
> org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(
> RAMTransaction.java:823)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.clean
> upTempTableOnCommitOrRollback(GenericLanguageConnectionContext.java:1345)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.doCom
> mit(GenericLanguageConnectionContext.java:1263)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.xaCom
> mit(GenericLanguageConnectionContext.java:1160)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.xa_commit(EmbedConnection.
> java:2921)
> ... 4 more
> See attached program for reproduction.
> javac -g ReproXATempTable.java utilXid.java
> java ReproXATempTable
> To work around the issue, you can drop the temp table before ending the xa
> transaction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
