Bug 895304
| Summary: | Cannot execute Two-Phase Commit using Multi-Source Model Dynamic VDB | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise SOA Platform 5 | Reporter: | Eiichi Nagai <enagai> |
| Component: | EDS | Assignee: | Jorge Perez Bolano <jperezbo> |
| Status: | CLOSED UPSTREAM | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 5.3.0 GA | CC: | soa-p-jira |
| Target Milestone: | ER4 | ||
| Target Release: | 5.3.1 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
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
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2025-02-10 03:27:17 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 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> updated the status of jira TEIID-2349 to Resolved 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. |
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: }