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: }
Steven Hawkins <shawkins> updated the status of jira TEIID-2349 to Resolved
Steven Hawkins <shawkins> 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.
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
Steven Hawkins <shawkins> updated the status of jira TEIID-2349 to Reopened
Steven Hawkins <shawkins> made a comment on jira TEIID-2349 Added the clone fix to 7.7.4
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.
Verified on SOA-P 5.3.1 ER4
Steven Hawkins <shawkins> updated the status of jira TEIID-2349 to Closed
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.