在Java中调用Oracle存储过程时如何避免核心转储

Question

My java program calls a stored procedure to parse files and load attributes in tables. This is a very time consuming step especially when it is doing soft delete (if a newer version of the same file comes in, instead of updating the old record, we set the delete flag of old record). The java program tends to wait until it finishes. In some occasions, when a great of number of files are being loaded to the db, java program would exit all of a sudden and generate core dumps. As a part of a big workflow, exiting of this job does not affect the rest of the steps. When it continues running, it would fail again at the next step (which also calls another stored procedure) with another core dump and hs_err_pid log file. However the stored procedure to load files would keep going until it finishes after a few hours. The timestamps of the core dumps indicate they are exactly when Oracle is doing soft deletes.

By reading the logs and core dumps, nothing tells me what went wrong. I debugged core dump using gdb and it only shows the error occurs during the call of the procedure. My guess is oracle was too busy loading files (soft deleting) and it was irresponsive at some point which caused my JVM to crash and thus the core dump. For similar reason, the job after this one would also have problem communicating with db since it is still overloaded.

Since there is SQL exception on Oracle side when it happens, there is nothing to catch. Is there a way to avoid the fatal error like this to prevent JVM from crashing? Or how can I tell Java to disconnect db once the stored procedure is called rather than listening to Oracle and only returns when procedure finishes.

Here is the java code I use to call the procedure:

try {
    CallableStatement stmt = conn.prepareCall("{call FILE_PROCESS.load_file(?,?,?,?,?,?,?,?,?)}");
    for (int i = 1; i < 10; i ++) {
        stmt.setString(i, arr[i - 1]);
    }
    stmt.registerOutParameter(7, Types.VARCHAR);
    stmt.registerOutParameter(8, Types.VARCHAR);
    stmt.registerOutParameter(9, Types.VARCHAR);
    stmt.executeUpdate();
    stmt.close();
    conn.close();
}
catch (SQLException e) {
    e.printStackTrace();
    System.exit(1);
}

EDIT: Another file 'hs_err_pid26342.log' was also generated by system at the same time. I pasted some of it below. It says something about SR_Handler. What is this method, and how is it called?

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00002b95187851d3, pid=26342, tid=47919353368928
#
# JRE version: 7.0-b147
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b17 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x6f31d3]  SR_handler(int, siginfo*, ucontext*)+0x43

Answer 1

how can I tell Java to disconnect db once the stored procedure is called rather than listening to Oracle and only returns when procedure finishes.

Look at DBMS_SCHEDULER.

Rather than the Java running

BEGIN
   file_load_stored_proc;
END;

you would have that coded into a scheduler job, then the java would tell the database to execute that job as a background task. The database will start the job in a separate database session and pass control back to the Java program immediately.

BEGIN
  DBMS_SCHEDULER.RUN_JOB('FILE_LOAD_JOB',false);
END;

You can configure the scheduler job to send emails if it fails (or even when it succeeds if you want that notification).

PS. I suspect a failure is occurring somewhere in the database execution and the Java is failing to cope with that cleanly giving the core dump. The scheduler job should allow better diagnosis of any problem there.