Workaround Description: If this is truly the case, then my vote is to KI this issue. Something along the lines of:

Teradata lobs can only be read from an embedded client using with the default option to use the calling thread and in single threaded mode (transactional or userRequestSourceConcurrency=1). Usage of Teradata lobs under any other configuration is unlikely to work.

Otherwise every Terardata lob Execution would have to either retain (leads to thread utilization issues) or reobtain (not generally possible, would require further customizing thread pooling logic) its executing thread to read the lob results. Neither of those options seems worth the effort.
project_key: SOA

The initial problem was seen when running BQT testing against the teradata source.   However, when debugging, the exception was occurring on the initial client read of the stream.    After reading teradata jdbc driver doc, it talks about how its not thread safe and has issues when different threads are handling blobs/clobs.   Which lead me to do a simple client test.   2 tests where run run thru a servlet that obtains the teradata connenction via jndi.   Thet are as follows (attached is the sample code after the changes used for #2):

1.   simple execute/select:   execute select intkey, objectvalue from bqt1.smalla,  for each row, obtain the clob and read the stream (no exception is seen)
2.   execute select and read clob in a different thread:     a new thread is created, passing in the clob, thread is started and then proceeds to try to read the stream, exceptions are seen


I'll attach the sample code.