The Ultimate Guide to High Availability with MariaDB

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).

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.