2

I'm using WildFly 10 with Hibernate and some JDBC. I have no logs at all If I declare my data source like this:

<datasource jta="true" jndi-name="java:jboss/Firebird" pool-name="FirebirdPool" enabled="true" spy="true" use-ccm="true" statistics-enabled="false">
<connection-url>jdbc:firebirdsql:localhost/3050:C:\banco\COMPLEXO140116.FDB</connection-url>

But if I declare passing:

?defaultResultSetHoldable=True&amp;encoding=WIN1252

it logs

09:54:00,384 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper (default task-3) SQL Warning Code: 0, SQLState: 01000

09:54:00,384 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-3) null

at every query

Community
  • 1
  • 1
erickdeoliveiraleal
  • 708
  • 2
  • 9
  • 21
  • These log messages are generated by Hibernate, do you have more info like a stacktrace or error message? Have you tried which of the two properties cause this (my guess would be `defaultResultSetHoldable=true`) – Mark Rotteveel Mar 04 '16 at 16:13

1 Answers1

3

The logging is done by Hibernate, not by Firebird or Jaybird. The reason this happens is because you have specified defaultResultSetHoldable=True. This setting will make all statements have holdability HOLD_CURSORS_OVER_COMMIT. In Jaybird HOLD_CURSORS_OVER_COMMIT is implemented by using TYPE_SCROLL_INSENSITIVE, but the default is TYPE_FORWARD_ONLY, so Jaybird upgrades the result set type, and in compliance with the JDBC specification (section 15.1.1 of JDBC 4.2), this registers a warning which is then logged by Hibernate.

If the driver does not support the type supplied to the methods createStatement, prepareStatement, or prepareCall, it generates an SQLWarning on the Connection object that is creating the statement.

Unfortunately, a bug in the SQLWarning subclass used by Jaybird causes the message to be null instead of the actual message ("Holdable result set must be scrollable.").

Your options are either not specifying defaultResultSetHoldable=True or configuring Hibernate to not log warnings using configuration property hibernate.jdbc.log.warnings=false.

Out of curiosity: why are you specifying defaultResultSetHoldable=True? It is an option that can be bad for performance as it caches the entire result set in the driver, and it is primarily intended as a workaround for applications that try to access the result set after (auto) commit.

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
  • I have a JSF application that uses JasperReport, when it calls the generation of PDF if the option `defaultResultSetHoldable=True` is not set, then I have an error. This is a known issue: [link](https://www.google.com.br/search?q=jasper+reports+"defaultResultSetHoldable%3DTrue") – erickdeoliveiraleal Mar 06 '16 at 18:48
  • Thanks, I will take a look at jasper reports, because it sounds like it is trying to use the result set after it has been closed. In auto commit, executing another statement on the same connection closes the result set of earlier executed statements as required by the JDBC specification. – Mark Rotteveel Mar 06 '16 at 19:02
  • So, in this case, should I have a connection with this parameter only for Jasper and another connection to the rest of application? – erickdeoliveiraleal Mar 07 '16 at 12:26
  • @erickdeoliveiraleal That would be advisable yes. – Mark Rotteveel Mar 07 '16 at 12:27
  • We are using defaultResultSetHoldable=True since we are batch processing large volumes of data using hibernate. We have millions of datasets and a commit size of about 1000. Another way to get rid of the warnings is to overwrite isJdbcLogWarningsEnabledByDefault in your own Firebird Dialect class. – B_St Feb 27 '19 at 12:06
  • @B_St If you are processing large volumes of data, it might be advisable not to use defaultResultSetHoldable=true as it will result in more memory consumption as the whole result set is loaded into memory first. – Mark Rotteveel Feb 27 '19 at 12:18
  • But if we use defaultResultSetHoldable=false the cursor will break as soon as we commit. How can we solve this problem? – B_St Feb 27 '19 at 13:31
  • @B_St Consider not committing, and use a read-only (read committed) transaction if you are concerned about the effects of long living transaction. – Mark Rotteveel Feb 27 '19 at 14:15