10:27 a.m.
Hi,
in a recent version of the HANA JDBC driver the new JDBC 4.3 features that came with Java
9 have been implemented. The driver itself is still compiled for Java 7 (javac -target
1.7). So the driver should also be usable with a JVM 7 or 8. This works as expected until
Java reflection is used to determine, for example, the existence of a method on the
connection class. Hibernate uses this approach in
org.hibernate.engine.jdbc.env.internal.DefaultSchemaNameResolver#determineAppropriateResolverDelegate
to determine if the connection class implements the #getSchema method. In this case the
JVM tries to load the entire connection class including the non-existing new interface
java.sql.ShardingKey. The result is a java.lang.NoClassDefFoundError being thrown which
isn't caught anywhere causing the Hibernate bootstrapping process to fail. I've
attached a sample stack trace to this mail.
Situations like this can also occur in other places, for example, when getting a
connection from a Hikari connection pool.
My question is now how you think Hibernate should handle situations like this. Do you see
it as a JDBC driver issue? Should Hibernate ignore the error and continue with a
conservative guess if possible (e.g. assume that the connection class doesn't
implement #getSchema)?
Thanks,
Jonathan
10:44 a.m.
Hi Jonathan,
personally this looks like an issue with the driver as class
initialization could be triggered by a number of things, it's going to
be hard to dodge them all, not least all containers and servers have
their own peculiarities in how they load and wrap drivers and
datasources; could you suggest the HANA JDBC team to release
multi-release jars? That would be safer, and also avoid issues with
other tools beyond Hibernate ORM.
- http://openjdk.java.net/jeps/238
Thanks,
Sanne
On 12 March 2018 at 15:27, Bregler, Jonathan <jonathan.bregler(a)sap.com> wrote:
Hi,
in a recent version of the HANA JDBC driver the new JDBC 4.3 features that came with Java
9 have been implemented. The driver itself is still compiled for Java 7 (javac -target
1.7). So the driver should also be usable with a JVM 7 or 8. This works as expected until
Java reflection is used to determine, for example, the existence of a method on the
connection class. Hibernate uses this approach in
org.hibernate.engine.jdbc.env.internal.DefaultSchemaNameResolver#determineAppropriateResolverDelegate
to determine if the connection class implements the #getSchema method. In this case the
JVM tries to load the entire connection class including the non-existing new interface
java.sql.ShardingKey. The result is a java.lang.NoClassDefFoundError being thrown which
isn't caught anywhere causing the Hibernate bootstrapping process to fail. I've
attached a sample stack trace to this mail.
Situations like this can also occur in other places, for example, when getting a
connection from a Hikari connection pool.
My question is now how you think Hibernate should handle situations like this. Do you see
it as a JDBC driver issue? Should Hibernate ignore the error and continue with a
conservative guess if possible (e.g. assume that the connection class doesn't
implement #getSchema)?
Thanks,
Jonathan
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:13 a.m.
Hi Sanne,
Multi-release JARs sound promising. I'll forward your suggestion to the HANA JDBC
driver team.
Thanks,
Jonathan
-----Original Message-----
From: sanne.grinovero(a)gmail.com [mailto:sanne.grinovero@gmail.com] On Behalf Of Sanne
Grinovero
Sent: Monday, March 12, 2018 4:45 PM
To: Bregler, Jonathan <jonathan.bregler(a)sap.com>
Cc: hibernate-dev(a)lists.jboss.org
Subject: Re: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM
versions
Hi Jonathan,
personally this looks like an issue with the driver as class
initialization could be triggered by a number of things, it's going to
be hard to dodge them all, not least all containers and servers have
their own peculiarities in how they load and wrap drivers and
datasources; could you suggest the HANA JDBC team to release
multi-release jars? That would be safer, and also avoid issues with
other tools beyond Hibernate ORM.
- http://openjdk.java.net/jeps/238
Thanks,
Sanne
On 12 March 2018 at 15:27, Bregler, Jonathan <jonathan.bregler(a)sap.com> wrote:
Hi,
in a recent version of the HANA JDBC driver the new JDBC 4.3 features that came with Java
9 have been implemented. The driver itself is still compiled for Java 7 (javac -target
1.7). So the driver should also be usable with a JVM 7 or 8. This works as expected until
Java reflection is used to determine, for example, the existence of a method on the
connection class. Hibernate uses this approach in
org.hibernate.engine.jdbc.env.internal.DefaultSchemaNameResolver#determineAppropriateResolverDelegate
to determine if the connection class implements the #getSchema method. In this case the
JVM tries to load the entire connection class including the non-existing new interface
java.sql.ShardingKey. The result is a java.lang.NoClassDefFoundError being thrown which
isn't caught anywhere causing the Hibernate bootstrapping process to fail. I've
attached a sample stack trace to this mail.
Situations like this can also occur in other places, for example, when getting a
connection from a Hikari connection pool.
My question is now how you think Hibernate should handle situations like this. Do you see
it as a JDBC driver issue? Should Hibernate ignore the error and continue with a
conservative guess if possible (e.g. assume that the connection class doesn't
implement #getSchema)?
Thanks,
Jonathan
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
10:20 a.m.
Out of curiosity, do you have a link to this new java.sql.ShardingKey
feature?
Other than that, I agree with Sanne - multiple jars (with proper classifier
once y'all publish your drivers) is the best option
On Mon, Mar 12, 2018 at 11:35 AM Bregler, Jonathan <jonathan.bregler(a)sap.com>
wrote:
Hi Sanne,
Multi-release JARs sound promising. I'll forward your suggestion to the
HANA JDBC driver team.
Thanks,
Jonathan
-----Original Message-----
From: sanne.grinovero(a)gmail.com [mailto:sanne.grinovero@gmail.com] On
Behalf Of Sanne Grinovero
Sent: Monday, March 12, 2018 4:45 PM
To: Bregler, Jonathan <jonathan.bregler(a)sap.com>
Cc: hibernate-dev(a)lists.jboss.org
Subject: Re: [hibernate-dev] Hibernate support for JDBC drivers targeting
multiple JVM versions
Hi Jonathan,
personally this looks like an issue with the driver as class
initialization could be triggered by a number of things, it's going to
be hard to dodge them all, not least all containers and servers have
their own peculiarities in how they load and wrap drivers and
datasources; could you suggest the HANA JDBC team to release
multi-release jars? That would be safer, and also avoid issues with
other tools beyond Hibernate ORM.
- http://openjdk.java.net/jeps/238
Thanks,
Sanne
On 12 March 2018 at 15:27, Bregler, Jonathan <jonathan.bregler(a)sap.com>
wrote:
> Hi,
>
> in a recent version of the HANA JDBC driver the new JDBC 4.3 features
that came with Java 9 have been implemented. The driver itself is still
compiled for Java 7 (javac -target 1.7). So the driver should also be
usable with a JVM 7 or 8. This works as expected until Java reflection is
used to determine, for example, the existence of a method on the connection
class. Hibernate uses this approach in
org.hibernate.engine.jdbc.env.internal.DefaultSchemaNameResolver#determineAppropriateResolverDelegate
to determine if the connection class implements the #getSchema method. In
this case the JVM tries to load the entire connection class including the
non-existing new interface java.sql.ShardingKey. The result is a
java.lang.NoClassDefFoundError being thrown which isn't caught anywhere
causing the Hibernate bootstrapping process to fail. I've attached a sample
stack trace to this mail.
>
> Situations like this can also occur in other places, for example, when
getting a connection from a Hikari connection pool.
>
> My question is now how you think Hibernate should handle situations like
this. Do you see it as a JDBC driver issue? Should Hibernate ignore the
error and continue with a conservative guess if possible (e.g. assume that
the connection class doesn't implement #getSchema)?
>
> Thanks,
> Jonathan
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:36 a.m.
I don’t have a specific link for the sharding feature. I just took a quick look at the
JDBC 4.3 spec. The overview of changes lists the following changes regarding sharding:
* Added support for Sharding.
Sharding is a scaling technique in which data is horizontally partitioned across
independent databases.
* Addition of the java.sql.ShardigKey interface
This interface is used to indicate that this object represents a Sharding Key. A
ShardingKey instance is only guaranteed to be compatible with the data source instance
that it was derived from.
* Addition of the java.sql.ShardingKeyBuilder interface
A builder created from a DataSource or XADataSource object, used to create a ShardingKey
with sub-keys of supported data types.
Just for completeness, there are other new interfaces that cause similar problems:
* Addition of the java.sql.ConnectionBuilder interface
A builder created from a DataSource object, used to establish a connection to the database
that the data source object represents.
* Addition of the javax.sql.XAConnectionBuilder interface
A builder created from a XADataSource object, used to establish a connection to the
database that the data source object represents.
* Addition of the javax.sql.PooledConnectionBuilder interface
A builder created from a PooledConnectionDataSource object, used to establish a connection
to the database that the data source object represents.
It looks like the HANA JDBC driver team will most likely go with multi-release JARs. If
everything goes as planned we’ll also publish the driver on Maven Central soon.
- Jonathan
From: Steve Ebersole [mailto:steve@hibernate.org]
Sent: Tuesday, March 13, 2018 4:21 PM
To: Bregler, Jonathan <jonathan.bregler(a)sap.com>
Cc: Sanne Grinovero <sanne(a)hibernate.org>; hibernate-dev(a)lists.jboss.org
Subject: Re: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM
versions
Out of curiosity, do you have a link to this new java.sql.ShardingKey feature?
Other than that, I agree with Sanne - multiple jars (with proper classifier once y'all
publish your drivers) is the best option
On Mon, Mar 12, 2018 at 11:35 AM Bregler, Jonathan
<jonathan.bregler@sap.com<mailto:jonathan.bregler@sap.com>> wrote:
Hi Sanne,
Multi-release JARs sound promising. I'll forward your suggestion to the HANA JDBC
driver team.
Thanks,
Jonathan
-----Original Message-----
From: sanne.grinovero@gmail.com<mailto:sanne.grinovero@gmail.com>
[mailto:sanne.grinovero@gmail.com<mailto:sanne.grinovero@gmail.com>] On Behalf Of
Sanne Grinovero
Sent: Monday, March 12, 2018 4:45 PM
To: Bregler, Jonathan
<jonathan.bregler@sap.com<mailto:jonathan.bregler@sap.com>>
Cc: hibernate-dev@lists.jboss.org<mailto:hibernate-dev@lists.jboss.org>
Subject: Re: [hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM
versions
Hi Jonathan,
personally this looks like an issue with the driver as class
initialization could be triggered by a number of things, it's going to
be hard to dodge them all, not least all containers and servers have
their own peculiarities in how they load and wrap drivers and
datasources; could you suggest the HANA JDBC team to release
multi-release jars? That would be safer, and also avoid issues with
other tools beyond Hibernate ORM.
- http://openjdk.java.net/jeps/238
Thanks,
Sanne
On 12 March 2018 at 15:27, Bregler, Jonathan
<jonathan.bregler@sap.com<mailto:jonathan.bregler@sap.com>> wrote:
Hi,
in a recent version of the HANA JDBC driver the new JDBC 4.3 features that came with Java
9 have been implemented. The driver itself is still compiled for Java 7 (javac -target
1.7). So the driver should also be usable with a JVM 7 or 8. This works as expected until
Java reflection is used to determine, for example, the existence of a method on the
connection class. Hibernate uses this approach in
org.hibernate.engine.jdbc.env.internal.DefaultSchemaNameResolver#determineAppropriateResolverDelegate
to determine if the connection class implements the #getSchema method. In this case the
JVM tries to load the entire connection class including the non-existing new interface
java.sql.ShardingKey. The result is a java.lang.NoClassDefFoundError being thrown which
isn't caught anywhere causing the Hibernate bootstrapping process to fail. I've
attached a sample stack trace to this mail.
Situations like this can also occur in other places, for example, when getting a
connection from a Hikari connection pool.
My question is now how you think Hibernate should handle situations like this. Do you see
it as a JDBC driver issue? Should Hibernate ignore the error and continue with a
conservative guess if possible (e.g. assume that the connection class doesn't
implement #getSchema)?
Thanks,
Jonathan
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org<mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org<mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2546
days inactive
2547
days old
4 comments
3 participants
participants (3)
-
Bregler, Jonathan -
Sanne Grinovero -
Steve Ebersole