[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1919: --------------------------------------- This isn't Teiid specific correct? Shouldn't this be logged against JBoss AS or JBoss Transactions? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1919: --------------------------------------- That doesn't make any sense. The only scenario we do anything remotely different is with inflow transations. Otherwise we're the same. Are truly similar scenarios being compared? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1919: --------------------------------------- Assuming that the -ds.xml files are identical between the two scenarios, can you provide the simple app and describe the teiid scenario (local/global transaction, embedded/remote client) details? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Johnathon Lee commented on TEIID-1919: -------------------------------------- The invoked procedure: CREATE VIRTUAL PROCEDURE BEGIN SELECT * INTO #temp FROM mashup; SELECT * INTO #temp2 FROM xatest2.TINYA; SELECT 1; END -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-1919: --------------------------------- Attachment: xatest.jsp non-teiid example. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1919: --------------------------------------- Here is what I've found so far. We do have an issue with Teiid embedded datasources that are using the calling thread under a user transaction, the exception there is that the thread is already active under a transaction. The fix is simple and I'll log a separate jira for that - also you can workaround by setting useCallingThread=false. For this issue in my setup I'm using exactly the same Oracle source information, but in two different datasources. They -ds.xml files are set with: <no-tx-separate-pools></no-tx-separate-pools> <track-connection-by-tx></track-connection-by-tx> <isSameRM-override-value>false</isSameRM-override-value> I put a simple dynamic vdb on top of those sources. I then modified the teiid and the non-teiid examples to then issue the same queries - 1 to each source under the user transaction. Two reads (as is presumably shown in the teiid procedue) or an insert then read resulted in no errors. So we still need to do a little more to narrow this down. I'm using ms_source from the case, can you provide me via email the other test credentials your using? Then also we need to repeat the non-teiid test using exactly the same source queries as are produced by the teiid plan. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-1919: ------------------------------------- useCallingThread=true is property either URL connection property or datasource property for Teiid JDBC Driver/Datasource, not generic JBoss datasource property. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-1919: ------------------------------------- It is one of custom properties on Teiid's datasource, because of fact that Teiid can take advantage of being the tenant of the same VM as the container (LocalConnection). When set, the user's calling thread is used all the way to execute operations under Teiid to execute the query. If you connect over the socket to Teiid or not sing useCallingThread=false, then a different processing worker thread is used for Teiid's processing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-1919: ------------------------------------- See this for LocalConnection http://docs.jboss.org/teiid/7.6.0.Final/client-developers-guide/en-US/htm... Yes, you need to set <xa-datasource-property name="useCallingThread">false</xa-datasource-property> Also when you use *mm://localhost:31000* in url (data source is configured without URL), even though it is same VM, you can not count that as LocalConnection as there is marshall/unmarshell going on between requests and response. See this for XA datasource http://docs.jboss.org/teiid/7.6.0.Final/client-developers-guide/en-US/htm... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1919: --------------------------------------- When I switch my simple test case to use a socket connection for teiid, I do get an exception. So it does make a difference that we're using our inflow transaction logic. I'll see what is different and if this is oracle specific. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-1919: ------------------------------------- when you omit the "ServerName" and "PortNumber" properties for your LocalConnection then it is considered in VM. When supply these, it is not and uses the socket to make connection in this case. In the case of when using a URL Local - jdbc:teiid:<vdb> Remote - jdbc:teiid:<vdb>@mm://<host>:port; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1919: --------------------------------------- However there is another catch, I reopened TEIID-1921 because an additional change was needed. In the embedded scenario, and if not using the calling thread, no transaction actually becomes associated with the work. With that change, the embedded case works with or without useCallingThread set. So this issue remains when using a socket connection. However we need to verify if it only happens with local socket connections vs. remote socket connections. There is likely a problem in the local case, since the inflow transaction is a new TransactionImple instance that has the Xid as an existing transaction. We then assume that the new transaction is specifically for use with Teiid - which it may not be since it logically duplicates an existing transaction. I'm not sure if there is a general fix we should attempt (how do we detect if the transaction already existed, do we need to use a different branch id, etc.) since at least in the local case the more appropriate path is to use an embedded datasource connection with the TEIID-1921 fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIID-1919 at 2/1/12 12:40 PM: ---------------------------------------------------------------- However there is another catch, I reopened TEIID-1921 because an additional change was needed. In the embedded scenario, and if not using the calling thread, no transaction actually becomes associated with the work. With that change, the embedded case works with or without useCallingThread set. So this issue remains when using a local socket connection. We need to verify if it only happens with local socket connections vs. remote socket connections. There is likely only a problem in the local case, since the inflow transaction is a new TransactionImple instance that has the same Xid as an existing transaction. We then assume that the new transaction is specifically for use with Teiid - which it may not be since it logically duplicates an existing transaction. I'm not sure if there is a general fix we should attempt (how do we detect if the transaction already existed, do we need to use a different branch id, etc.) since at least in the local case the more appropriate path is to use an embedded datasource connection with the TEIID-1921 fix. was (Author: shawkins): However there is another catch, I reopened TEIID-1921 because an additional change was needed. In the embedded scenario, and if not using the calling thread, no transaction actually becomes associated with the work. With that change, the embedded case works with or without useCallingThread set. So this issue remains when using a local socket connection. However we need to verify if it only happens with local socket connections vs. remote socket connections. There is likely a problem in the local case, since the inflow transaction is a new TransactionImple instance that has the Xid as an existing transaction. We then assume that the new transaction is specifically for use with Teiid - which it may not be since it logically duplicates an existing transaction. I'm not sure if there is a general fix we should attempt (how do we detect if the transaction already existed, do we need to use a different branch id, etc.) since at least in the local case the more appropriate path is to use an embedded datasource connection with the TEIID-1921 fix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-1919: ---------------------------------- Workaround Description: With TEIID-1921 resolved, use a local DataSource connection by not setting the ServerName and PortNumber DataSource properties. Workaround: Workaround Exists -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-1919: ------------------------------------- John, can you deploy your web app into a separate jboss container and keep the Teiid in old container and see if this issue still occurs? I would like to confirm this scenario works. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-1919: ------------------------------------- The -Djboss.service.binding.set=ports-01 is used for port offset in the case of JBoss instances are used in a cluster and multiple instances of JBoss on the same box. However, the above might work also! The intent is right, I want your JSP on one JBoss Server and Teiid instance in another server. Hopefully on a different machine, but if you can configure on same machine then it is fine too. Just two distinct VMs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-1919: ------------------------------------- Have changed the -ds.xml file to use the "serverName" and "portNumber" for Teiid, as now Teiid lives in a remote VM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-1919: ------------------------------------- None from above. There are two solutions available you. 1) Add TEIID-1921 as fix and use "Local/embedded" connection, it does not matter useCallingThread=false. This is recommended. 2) Second is 2 VM solution with host:port specified on -ds.xml file where your JSP file is deployed (not local connection). From your comments I not sure you have configured it correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-1919: ------------------------------------- (2) I have not, I was hoping you can as you have all the environment set up. Previously yes, I want find out if there was any regression. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1919?page=com.atlassian.jira.plugin... ] Johnathon Lee commented on TEIID-1919: -------------------------------------- I'm feeling very thick headed here (not meaning to be). 1) I've looked at TEIID-1921. If the purpose of looking is to see that I don't get anything working without the fix, then I understand and you can disregard the rest of this post while I back pedal to apply. If not... 2) My understanding is that by deploying the application in a different container, I force the inability of the container hosting the xatest.vdb to not be able to use the calling thread. - On the JBoss install I've deployed xatest.vdb, which utilizes xatest1-ds.xml[1] and xatest2-ds.xml[2] - On the JBoss2 install which hosts the xasimple.jsp, I've defined the following xatestvdb-ds.xml[3]. The xatest.vdb is not deployed in the JBoss2 instance nor are xatest1-ds.xml or xatest2-ds.xml defined there. - When I run xasimple.jsp on JBoss2, I receive [4] on the .jsp and [5] snippet in the JBoss server.log [1] <datasources> <xa-datasource> <jndi-name>xatest1</jndi-name> <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class> <xa-datasource-property name="URL">jdbc:oracle:thin:@<host>:<port>:ds08</xa-datasource-property> <xa-datasource-property name="User">xxxx</xa-datasource-property> <xa-datasource-property name="Password">xxxx</xa-datasource-property> <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name> <no-tx-separate-pools></no-tx-separate-pools> <track-connection-by-tx></track-connection-by-tx> <isSameRM-override-value>false</isSameRM-override-value> <metadata> <type-mapping>Oracle9i</type-mapping> </metadata> </xa-datasource> </datasources> [2] <datasources> <xa-datasource> <jndi-name>xatest2</jndi-name> <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class> <xa-datasource-property name="URL">jdbc:oracle:thin:@<host>:<port>:ds08</xa-datasource-property> <xa-datasource-property name="User">differentxxxx</xa-datasource-property> <xa-datasource-property name="Password">differentxxxx</xa-datasource-property> <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name> <no-tx-separate-pools></no-tx-separate-pools> <track-connection-by-tx></track-connection-by-tx> <isSameRM-override-value>false</isSameRM-override-value> <metadata> <type-mapping>Oracle9i</type-mapping> </metadata> </xa-datasource> </datasources> [3] <datasources> <xa-datasource> <jndi-name>xatestvdb</jndi-name> <xa-datasource-class>org.teiid.jdbc.TeiidDataSource</xa-datasource-class> <xa-datasource-property name="DatabaseName">xatest</xa-datasource-property> <xa-datasource-property name="serverName">localhost</xa-datasource-property> <xa-datasource-property name="portNumber">31000</xa-datasource-property> <xa-datasource-property name="user">xxxx</xa-datasource-property> <xa-datasource-property name="password">xxxx</xa-datasource-property> <xa-datasource-property name="AdditionalProperties">useCallingThread=false</xa-datasource-property> <no-tx-separate-pools></no-tx-separate-pools> <track-connection-by-tx></track-connection-by-tx> <isSameRM-override-value>false</isSameRM-override-value> <!-- pool and other JBoss datasource properties --> <min-pool-size>5</min-pool-size> <max-pool-size>10</max-pool-size> <metadata> <type-mapping>jdbc</type-mapping> </metadata> <!-- pool and other JBoss datasource properties --> <check-valid-connection-sql>SELECT 1</check-valid-connection-sql> </xa-datasource> </datasources> [4] org.teiid.jdbc.TeiidSQLException: xatest2: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < jca-subordinate, BasicAction: 7f000001:b1fa:4f29af8a:9b63 status: ActionStatus.ABORT_ONLY >); - nested throwable: (org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImple < jca-subordinate, BasicAction: 7f000001:b1fa:4f29af8a:9b63 status: ActionStatus.ABORT_ONLY >)) [5] 2012-02-02 10:13:38,578 INFO [STDOUT] (Worker9_QueryProcessorQueue28) DRVR OPER OracleCallableStatement.sendBatch() 2012-02-02 10:13:38,707 WARN [org.jboss.resource.connectionmanager.TxConnectionManager] (Worker9_QueryProcessorQueue28) Connection error occured: org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener@115fe475[state=NORMAL mc=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection@611fa505 handles=0 lastUse=1328199218181 permit=true trackByTx=true mcp=org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool@27f6cda0 context=org.jboss.resource.connectionmanager.InternalManagedConnectionPool@3c35d7df xaResource=org.jboss.resource.adapter.jdbc.xa.XAManagedConnection@611fa505 txSync=null] oracle.jdbc.xa.OracleXAException at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1223) at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:318) at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:799) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:510) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.enlist(TxConnectionManager.java:985) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira