Problem with stored procedures after migration from mysql to mariadb with jdbc driver from mariadb
I have a problem with stored procedures after migration from mysql to mariadb 10.1. With the old jdbc driver from mysql mysql-connector-java-5.1.13-bin all is ok. If i change the driver to the mariadb driver mariadb-java-client-1.3.6 it's not ok. Here the queries.log:
2 Query set @_jdbc_var_1='Check',@_jdbc_var_2='',@_jdbc_var_3='Benutzer',@_jdbc_var_4='Aktuell',@_jdbc_var_5='Passwort',@_jdbc_var_6=NULL,@_jdbc_var_7=0,@_jdbc_var_8='Administrator',@_jdbc_var_9='7b7bc2512ee1fedcd76bdc68926d4f7b',@_jdbc_var_10=NULL,@_jdbc_var_11=NULL,@_jdbc_var_12=NULL,@_jdbc_var_13=0,@_jdbc_var_14=0,@_jdbc_var_15=0 2 Query call spmzBenutzer(@_jdbc_var_1,@_jdbc_var_2,@_jdbc_var_3,@_jdbc_var_4,@_jdbc_var_5,@_jdbc_var_6,@_jdbc_var_7,@_jdbc_var_8,@_jdbc_var_9,@_jdbc_var_10,@_jdbc_var_11,@_jdbc_var_12,@_jdbc_var_13,@_jdbc_var_14,@_jdbc_var_15) 2 Query SET @AKTIO NAME_CONST('p_AKTION',_utf8'Check' COLLATE 'utf8_general_ci')TION 2 Query SET @Sortierun NAME_CONST('p_Sortierung',_utf8'' COLLATE 'utf8_general_ci')rung 2 Query SET @MODU NAME_CONST('p_MODUS',_utf8'Benutzer' COLLATE 'utf8_general_ci')ODUS 2 Query SET @MODUS NAME_CONST('p_MODUS2',_utf8'Aktuell' COLLATE 'utf8_general_ci')DUS2 2 Query SET @MODUS NAME_CONST('p_MODUS3',_utf8'Passwort' COLLATE 'utf8_general_ci')DUS3 2 Query SET @IDBenutze NAME_CONST('p_IDBenutzer',0)tzer 2 Query SET @Benutze NAME_CONST('p_Benutzer',_utf8'Administrator' COLLATE 'utf8_general_ci')tzer 2 Query SET @Passwor NAME_CONST('p_Passwort',_utf8'7b7bc2512ee1fedcd76bdc68926d4f7b' COLLATE 'utf8_general_ci')wort 2 Query SET @Vornam NAME_CONST('p_Vorname',NULL)name 2 Query SET @Nachnam NAME_CONST('p_Nachname',NULL)name 2 Query SET @AnlegeDatu NAME_CONST('p_AnlegeDatum',NULL)atum 2 Query SET @Statu NAME_CONST('p_Status',0)atus 2 Query SET @IDRo NAME_CONST('p_IDRow',0)DRow 2 Query SET @IDGrupp NAME_CONST('p_IDGruppe',0)uppe 2 Query SELECT IDBenutzer into p_NeuerIdent FROM bvwbenutzer WHERE Benutzer = @Benutzer AND Passwort = @Passwort AND Status < 9 2 Query SELECT NULL,NULL,NULL,NULL,NULL,@_jdbc_var_6,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL 2 Query ROLLBACK
And here the jbossprotokol:
2016-03-24 11:02:55,313 ERROR [org.jboss.ejb.plugins.LogInterceptor] (WorkerThread#0[10.19.12.113:50404]) EJBException in method: public abstract java.lang.Integer mmts.benutzer.interfaces.BenutzerFacade.Pruefen_Benutzer_Passwort(java.lang.String,java.lang.String) throws java.rmi.RemoteException, causedBy: java.sql.SQLException: CallableStatement.executeQuery() did not return a resultset at org.mariadb.jdbc.MariaDbCallableStatement.executeQuery(MariaDbCallableStatement.java:1268) at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:342) at mmts.benutzer.ejb.BenutzerFacade.Pruefen_Benutzer_Passwort(BenutzerFacade.java:551)
Who can help me?
Answer Answered by Diego Dupin in this comment.
Hi, This was happening because following the JDBC API, a call to CallableStatement.executeQuery() must return a resultset (method inheritance from http://docs.oracle.com/javase/7/docs/api/java/sql/PreparedStatement.html#executeQuery())
You'll tell if i'm correct, but i assume the query {call spmzBenutzer(...)} must not have any resultset. That why this exception was thrown.
I agree this is too harsh. Version 1.4 is released with a rewritten implementation of CallableStatement. Now, In this case, no exception is thrown, just an empty resultset (i've just test it and this is similar to what the MySQL connector is doing).