Embedded Teiid with JDBC specification

[anjeshkumar]

I am using the Embedded Teiid connection for my VDB and expecting it should follows the JDBC specification i.e. all JDBC API's method should be executable. I am getting expection whild fetching meta-data of VDB using JDBC methods.

Using these command for getting Connection :

  EmbeddedServer server = OWTEmbeddedConnect.launchEmbeddedServer("anjesh", "anjesh", "sid", "schema");

  Connection  _connection = OWTEmbeddedConnect.createEmbeddedConnection(server, "anjesh");

Able to established connection Successfully.

For getting Tables name using JDBC calls over embedded teiid connection  :

ResultSet rs = _connection.createStatement().executeQuery("Select * from Sys.Tables") ;

OR

DatabaseMetaData dbMetaData = _connection.getMetaData();

ResultSet rs =  dbMetaData.getTables(null, null, "%", null);

In both calls, I am getting same exception :

SEVERE: TEIID30019 Unexpected exception for request 21ER/Uelhzdz.0

1. java.lang.IllegalAccessError: tried to access field org.teiid.core.types.DataTypeManager.USE_VALUE_CACHE from class org.teiid.common.buffer.impl.BufferManagerImpl

       at org.teiid.common.buffer.impl.BufferManagerImpl.persistBatchReferences(BufferManagerImpl.java:804)

       at org.teiid.common.buffer.impl.BufferManagerImpl.reserveBuffers(BufferManagerImpl.java:665)

       at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:224)

       at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:136)

       at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:112)

       at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:153)

       at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:435)

       at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:320)

       at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)

       at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:248)

       at org.teiid.dqp.internal.process.DQPCore.executeRequest(DQPCore.java:307)

       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

       at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

       at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

       at java.lang.reflect.Method.invoke(Unknown Source)

       at org.teiid.transport.LocalServerConnection$1$1.call(LocalServerConnection.java:135)

       at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)

       at java.util.concurrent.FutureTask.run(Unknown Source)

       at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:269)

       at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:253)

       at org.teiid.transport.LocalServerConnection$1.invoke(LocalServerConnection.java:133)

       at com.sun.proxy.$Proxy7.executeRequest(Unknown Source)

       at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:635)

       at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:510)

I have some questions :

1. Does Embedded Teiid connection should support JDBC specification ?

2. How can I use lighter version of embedded teiid without deploying it on JBOSS AS and should follows JDBC specification ?

[shawkins]

> 1. Does Embedded Teiid connection should support JDBC specification ?

This isn't a JDBC issue.  Teiid does support most of the JDBC api through JRE 1.6/1.7 - see also Unsupported JDBC Methods - Teiid 8.5 (draft) - Project Documentation Editor

Can you clarify your deployment scenario?  Are you talking about the Teiid Embedded Kit or using a local connection to Teiid in JBoss AS?

More than likely this is being caused by a mismatch of Teiid jars or some other deployment error. 

> 2. How can I use lighter version of embedded teiid without deploying it on JBOSS AS and should follows JDBC specification ?

The Teiid Embedded Kit does not require JBoss AS for use.  However you take responsibility for much of the container provided functionality, such as configuring through an API, establishing connection pools, providing the transaction manager, etc. 

Keep in mind there is limited documentation for this and there is no difference in the level of JDBC support with this option (again what you are seeing is not a JDBC issue).