-
Bug
-
Resolution: Done
-
Critical
-
None
-
None
-
DV Sprint 55, DV Sprint 56, DV Sprint 58
-
1
An attempt to set the isolation level on pg 42.2.8 resulted in an exception SQLSTATE 0a000 - unsupported - which causes the connection pool to mark the connection as broken:
2019-11-25 23:07:50.125 WARN 43993 --- [ProcessorQueue6] com.zaxxer.hikari.pool.ProxyConnection : HikariPool-1 - Connection org.postgresql.jdbc.PgConnection@2ffebc7e marked as broken because of SQLSTATE(0A000), ErrorCode(0)
org.postgresql.util.PSQLException:
at org.postgresql.jdbc.PgConnection.setTransactionIsolation(PgConnection.java:851) ~[postgresql-42.2.8.jar:42.2.8]
at com.zaxxer.hikari.pool.ProxyConnection.setTransactionIsolation(ProxyConnection.java:407) ~[HikariCP-3.2.0.jar:na]
at com.zaxxer.hikari.pool.HikariProxyConnection.setTransactionIsolation(HikariProxyConnection.java) ~[HikariCP-3.2.0.jar:na]
at org.teiid.translator.jdbc.JDBCBaseExecution.<init>(JDBCBaseExecution.java:72) ~[translator-jdbc-12.3.0.jar:12.3.0]
[TEIIDSB-144] Calling setTransactionIsolation on pg driver causes the connection to be closed
Steven Hawkins
added a comment - His hack does not need to obtain a connection as the field is static. I've put in a pr to add something similar. However if there are additional error codes we'll need to expand this. Also it affects all datasources, not just pg. It will be good to eventually have the a better solution.
Steven Hawkins
added a comment - His hack does not need to obtain a connection as the field is static. I've put in a pr to add something similar. However if there are additional error codes we'll need to expand this. Also it affects all datasources, not just pg. It will be good to eventually have the a better solution. Possible workaround as a patch which applies for any feature not implemented cases https://github.com/brettwooldridge/HikariCP/issues/1489#issuecomment-574390990
Steven Hawkins
added a comment - We could add a configuration processor to set both properties if either is present... but that will only fix the simplest case and could eventually look like us trying to create a datasource abstraction layer.
Would you rather take the proxy approach, or introduce our own patch of the proposed hikari fix (which has been open for over a month)?
Steven Hawkins
added a comment - We could add a configuration processor to set both properties if either is present... but that will only fix the simplest case and could eventually look like us trying to create a datasource abstraction layer.
Would you rather take the proxy approach, or introduce our own patch of the proposed hikari fix (which has been open for over a month)? Looks like if "tomcat-jdbc" is used, then URL property needs to be changed from "jdbc-url" to "url" this will have ripple effects all through teiid-syndesis and examples.
Steven Hawkins
added a comment - Either way. I was just flipping it to no longer in progress given the break.
Steven Hawkins
added a comment - Either way. I was just flipping it to no longer in progress given the break. Steven Hawkins
added a comment - Sounds like the plan is to move back to tomcat-jdbc then and make the appropriate changes at least in teiid-syndesis.
Steven Hawkins
added a comment - Sounds like the plan is to move back to tomcat-jdbc then and make the appropriate changes at least in teiid-syndesis. I did start out with tomcat-jdbc, however when we moved to Spring 2.x the default was Hikari, rather than going after explicitly disabling it, I just tried to use it. I guess we should move now, I can't think of any reason to stay with Hikari. If this is fixed in future we can look back.
Added the reflective workaround as a side effect of loading the teiid auto configuration.