Execute anonymous PL/SQL block via JDBC - OUT parameter not available

Question

I have a simple proc on the database:
CREATE PROCEDURE TEST(X OUT BINARY_INTEGER, Y IN VARCHAR) AS
BEGIN
  X := 33;
END; I am trying to invoke it via JDBC using an anonymous PL/SQL block:
        try {
            Connection connection =
              DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:ORCL",
                "scott", "tiger");
            CallableStatement stproc_stmt = connection.prepareCall(
                "DECLARE\n" +
                " X_TARGET BINARY_INTEGER;\n" +
                " Y_TARGET VARCHAR(20) := :2;\n" +
                "BEGIN\n" +
                " TEST(X=>X_TARGET, Y=>Y_TARGET);\n" +
                " :1 := X_TARGET;\n" +
                "END;"
            stproc_stmt.registerOutParameter(1, Types.NUMERIC);
            stproc_stmt.setString(2, "test");
            stproc_stmt.executeUpdate();
            Object o = stproc_stmt.getObject(1);
        catch (Exception e) {
            e.printStackTrace();
        } No exceptions are thrown, but the Object o does not get the value '33' - it is NULL.
Any ideas?
thanks in advance,
Mike Norman

Answer 1

I think the issue may be in how JDBC parameter binding is being managed throughout the block's lifecycle.
The slightly-different TEST2 works:
CREATE PROCEDURE TEST2(Y IN VARCHAR, X OUT BINARY_INTEGER) AS
BEGIN
  X := 33;
END;
try {
    Connection connection =
      DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:ORCL",
     "scott", "tiger");
    CallableStatement stproc_stmt = connection.prepareCall(
     "DECLARE\n" +
     " Y_TARGET VARCHAR(20) := :1;\n" +
     " X_TARGET BINARY_INTEGER;\n" +
     "BEGIN\n" +
     " TEST2(Y=>Y_TARGET, X=>X_TARGET);\n" +
     " :2 := X_TARGET;\n" +
     "END;"
    stproc_stmt.setString(1, "test");
    stproc_stmt.registerOutParameter(2, Types.NUMERIC);
    stproc_stmt.executeUpdate();
    Object o = stproc_stmt.getObject(1);
catch (Exception e) {
    e.printStackTrace();
}The order of the bind indices ':1' and ':2' are reversed in the above anonymous block - we are returning via ':2'.
I am wondering if 'under the covers' there isn't perhaps a cursor issue. When the original block is parsed and the first bind index is found to be position 2, somehow we can't go back to position 1 - a forwards-only cursor?