Bug 895304 - Cannot execute Two-Phase Commit using Multi-Source Model Dynamic VDB
Summary: Cannot execute Two-Phase Commit using Multi-Source Model Dynamic VDB
Status: VERIFIED
Alias: None
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: EDS
Version: 5.3.0 GA
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ER4
: 5.3.1
Assignee: Eiichi Nagai
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-15 02:07 UTC by Eiichi Nagai
Modified: 2018-12-01 17:33 UTC (History)
2 users (show)

(edit)
Users are experiencing problems when updating on multi-source models. 

If you are performing updates on multi-source models and using the default PROP_TXN_AUTO_WRAP of DETECT, then try to explicitly set the transaction mode by using of the following methods: 

* local (START TRANSACTION or setAutoCommit(false) 
* global/XA 
* set autoCommitTxn=ON on the URL
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker TEIID-2349 Major Closed Cannot execute Two-Phase Commit using Multi-Source Model Dynamic VDB 2018-12-02 23:49 UTC

Description Eiichi Nagai 2013-01-15 02:07:07 UTC
Description of problem:
2nd connection to Multi-Source Model Dynamic VDB is not Two-Phase Commit.

How reproducible:
Always

Steps to Reproduce:
Execute a update query via Multi-Source Model Dynamic VDB.
ex) 
vdb - maseter-vdb.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<vdb name="MASTER-VDB" version="1">
  <description>A Dynamic VDB</description>
  <property name="UseConnectorMetadata" value="true" />
  <model visible="true" type="PHYSICAL" name="VDB1">
    <property name="supports-multi-source-bindings" value="true" />
    <source name="db02" translator-name="postgresql" connection-jndi-name="java:/PostgresXADS02" />
    <source name="db01" translator-name="postgresql" connection-jndi-name="java:/PostgresXADS01" />
  </model>
</vdb>
  
Additional info:
Set the multisourceUpdate flag as first query plan creating.

org.teiid.dqp.internal.process.multisource.MultiSourcePlanToProcessConverter.java
90:  @Override
91:  public synchronized RelationalPlan convert(PlanNode planNode)
92:      throws QueryPlannerException, TeiidComponentException {
93:      RelationalPlan result = null;
94:    try {
95:      result = super.convert(planNode);
96:      return result;
97:    } finally {
98:      if (result != null && update && multiSource) {
-> 99:        result.setMultisourceUpdate(true);
100:      }
101:      update = false;
102:      multiSource = false;
103:    }
104:  }

If multisourceUpdate is true, transactionService is started by teiid engine. But, second connects does not set the multisourceUpdate flag. Therefore, teiid engine does not start transactionService. 

org.teiid.dqp.internal.process.Request.java
338:  private void createProcessor() throws TeiidComponentException {
--- snip ---
349:    if(RequestMessage.TXN_WRAP_ON.equals(requestMsg.getTxnAutoWrapMode())){ 
350:      startAutoWrapTxn = true;
351:    } else if (RequestMessage.TXN_WRAP_DETECT.equals(requestMsg.getTxnAutoWrapMode())){
352:      boolean transactionalRead = requestMsg.getTransactionIsolation() == Connection.TRANSACTION_REPEATABLE_READ
353:        || requestMsg.getTransactionIsolation() == Connection.TRANSACTION_SERIALIZABLE;
-> 354:        startAutoWrapTxn = processPlan.requiresTransaction(transactionalRead);
355:    } 
356:
357:    if (startAutoWrapTxn) {
358:      try {
-> 359:        transactionService.begin(tc);
360:      } catch (XATransactionException err) {
361:        throw new TeiidComponentException(err);
362:      }
363:    }
364:  }

org.teiid.query.processor.relational.RelationalPlan.java
254:  @Override
255:  public boolean requiresTransaction(boolean transactionalReads) {
256:    if (multisourceUpdate) {
-> 257:      return true;
258:    }
259:    if (this.with != null) {
260:      if (transactionalReads) {
261:        return true;
262:      }
263:      for (WithQueryCommand withCommand : this.with) {
264:        if (withCommand.getCommand().getProcessorPlan().requiresTransaction(transactionalReads)) {
265:          return true;
266:        }
267:      }
268:    }
279:    return requiresTransaction(transactionalReads, root);
270:  }

Comment 1 JBoss JIRA Server 2013-01-15 13:54:15 UTC
Steven Hawkins <shawkins@redhat.com> updated the status of jira TEIID-2349 to Resolved

Comment 2 JBoss JIRA Server 2013-01-15 13:54:15 UTC
Steven Hawkins <shawkins@redhat.com> made a comment on jira TEIID-2349

This was mainly addressed by TEIID-2091 which added better transaction detection logic and removed the need for explicitly having the multi-source update flag.  Teiid 8.2 went further to refine multi-source planning and removed the associated flag from the RelationalPlan.  The simpliest direct fix for older branches would be to clone the multisourceupdate flag setting in the RelationalPlan clone method.

Comment 8 Van Halbert 2013-01-15 15:55:18 UTC
Eiichi,

The fix is targeted to be out in the upcoming 5.3.1 release.  But until then, can you get them to try one of the below options to confirm there is a work around for this issue?


Any explicit transaction will work:
* local (START TRANSACTION or setAutoCommit(false)
* global/XA
* set autoCommitTxn=ON on the URL

Comment 9 Van Halbert 2013-01-15 15:55:50 UTC
Eiichi,

The fix is targeted to be out in the upcoming 5.3.1 release.  But until then, can you get them to try one of the below options to confirm there is a work around for this issue?


Any explicit transaction will work:
* local (START TRANSACTION or setAutoCommit(false)
* global/XA
* set autoCommitTxn=ON on the URL

Comment 10 JBoss JIRA Server 2013-01-15 16:58:55 UTC
Steven Hawkins <shawkins@redhat.com> updated the status of jira TEIID-2349 to Reopened

Comment 11 JBoss JIRA Server 2013-01-15 16:59:30 UTC
Steven Hawkins <shawkins@redhat.com> updated the status of jira TEIID-2349 to Resolved

Comment 12 JBoss JIRA Server 2013-01-15 16:59:30 UTC
Steven Hawkins <shawkins@redhat.com> made a comment on jira TEIID-2349

Added the clone fix to 7.7.4

Comment 13 Eiichi Nagai 2013-01-16 00:58:14 UTC
Hi Van,

Thank you for your update.

> But until then, can you get them to try one of the below options to confirm there is a work around for this issue?

I tried setAutoCommit(false). Yes, Explicit transaction is working. They become the workaround.

Comment 15 Filip Elias 2013-02-06 18:11:44 UTC
Verified on SOA-P 5.3.1 ER4

Comment 16 JBoss JIRA Server 2013-03-25 16:14:15 UTC
Steven Hawkins <shawkins@redhat.com> updated the status of jira TEIID-2349 to Closed


Note You need to log in before you can comment on or make changes to this bug.