Need DataSource implemented

[erik777]

Having a DataSource interface opens a lot of doors, as there are things designed to only work with one. In a container, such as Wildfly, it allows you to leverage container connection pooling. Frameworks such as Hibernate leverage a DataSource.

To be sure, I am not sure what implementing a DataSource means, or Crate means when it says it isn't supported, or what options the client-side developer has today. Please clarify if I am on the wrong track with this request. Let me share the original problem, which could be completely unrelated to Crate not supporting DataSource today.

I am trying to use a DataSource in Wildfly-swarm to leverage connection pooling. When I run the app, Wildfly outputs this exception:

2017-07-15 11:20:03,621 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) WFLYJCA0005: Deploying non-JDBC-compliant driver class io.crate.client.jdbc.CrateDriver (version 2.1)

Any idea why Wildfly views the driver as "non-JDBC-compliant"?

The lookup to the DataSource then results in Caused by: javax.naming.NameNotFoundException: jboss/datasources/ExampleDS -- service jboss.naming.context.java.jboss.datasources.ExampleDS

I understand that JDBC drivers can provide connection pooling, and that not supporting DataSource suggests that crate-jdbc does not include pooling today. But, do app servers such as Wildfly rely on it, or do they just use their connection pooling? If the latter, then the driver doesn't need it for Wildfly. But, then that leaves the question, what is required to get Wildfly to provide the DataSource for crate-jdbc? Is whatever is causing Wildfly to view it as a "non-JDBC-compliant driver class" the blocker?

[joemoe]

Hi @erik777,

as having distributed transactions is an essential part of the JDBC datasource interface and we don't support transactions it is not implemented yet. At the moment most of our users doing connection pooling are using Hikari.

We haven't yet tested CrateDB and CrateDB JDBC with Wildfly yet, but I assume that not having datasource implemented could lead to this error. To make that sure, we don't support all the JDBC features, but when we do, we implement them a 100 % standard compliant. But yes, I guess having a feature not implemented, probably throwing a "Feature not implemented exception" could cause this problem.

Cheers, Johannes

[erik777]

Thank you for the response. I was going to default to Apache DBCP, but you pointed me to what appears to be a better direction.