JBossDeveloper

Ultimately you need to know what the behavior of EclipseLink - when is a thread-bound transaction started, if/when is it calling setAutoCommit(false) and commit() to know exactly what connection settings you'll need to use in a local scenario.  The code that is in Teiid now will prevent us from inappropriately starting a subtransation, so leaving disableLocalTxn off is fine.  Only if you see an exception related to starting a subtransaction would you need to set that property.

Steve

My understanding was that socket based connections (even in the same VM) are always remote connections. Is that the reason why disableLocalTxn=true is causing problems? But shouldn't local transactions be disabled because we are using remote connections?

The terminology may be getting in the way here:

* A Teiid local connection is a non-socket connection to a Teiid instance (Embedded or Server) in the same VM.

* A local transaction (as opposed to an XA transaction) is logically scoped to the current JDBC connection and controlled through the Connection setAutoCommit, commit, and rollback methods (and sometimes by direct statements such as "START TRANSACTION")

My last post was assuming that you meant you were using a Teiid local connection - which does not have a well defined path for supporting a local transaction while a thread-bound transaction already exists.  Thus for a local connection you may need to use disableLocalTxn if your intent is to instead rely on the existence of a thread-bound transaction.

For a socket connection setting disableLocalTxn is likely not what you want to do as Teiid will be completely unaware of any explicit local transaction boundary and unaware of an thread-bound transaction associated with the calling thread because a different (socket thread) will be used to process the socket traffic.

In almost all situations it is preferable to use a local connection rather than a socket connection when you're accessing a Teiid instance in the same VM.  In some scenarios using a local transaction as a 1-PC commit workaround with a socket connection to the same vm can cause issues.  If for example you are using the sources outside of the Teiid transaction, but expect all of the work to logically be under the same transaction.