Corporate Info | News | Solutions | Products | Partners | Services | Events | Download | How To Buy

# Troubleshooting JDBC Hangs and SEGVs Contents Problems with Oracle Out-of-Memory errors Codeset Support Problems with Oracle on UNIX Thread-related Problems on UNIX Closing JDBC objects ## Problems with Oracle Several conditions can cause segmentation violation errors (SEGVs) or hangs when you use JDBC and an Oracle database. The most common cause is using Oracle client libraries prior to version 7.3.4. There are some known bugs in these libraries. You must upgrade to the current client libraries, as specified in Platform support for WebLogic jDriver JDBC drivers. You may be using WebLogic classes with a mismatched version of the .dll, .sl, or .so for WebLogic jDriver for Oracle. For example, when you install version 5.1 of WebLogic, you must upgrade your WebLogic jDriver for Oracle native library to version 3.0. You must always use the .dll, .so, or .sl file that was shipped with a particular version of the WebLogic distribution. You may have exhausted the available connections in a connection pool. Make sure that your program calls the close() method on the connection after you are finished with it. If you need more connections, increase the size of the pool. If the Oracle server and WebLogic are running on the same host, and you are using an IPC connection to Oracle, the version of your client libraries must match the version of your server. Note that when server and client are on the same host, sqlnet will by default, attempt to make an IPC connection. You can prevent this by specifying "automatic_ipc"=off in your sqlnet.ora file. If you have Oracle server and WebLogic on the same host and the Oracle Server is NOT the same version as the client libraries we link to, then you must turn off IPC. Your ORACLE_HOME environment variable may not be set correctly. You must set ORACLE_HOME correctly so that the OCI libraries can locate needed resource files. ### Out-of-Memory Errors A common cause of out-of-memory errors is failing to close ResultSets. The error message is usually similiar to the following:
    Run-time exception error; current exception: xalloc
    No handler for exception
When using array fetches, the native layer allocates memory in C, not in Java, so Java garbage collection does not immediately clean up the memory. The only way to release the memory is to close the ResultSet. (You can minimize this memory usage for better performance.) To avoid out-of-memory errors, make sure that your program logic closes any ResultSets in all cases. To test whether failing to close ResultSets is causing the out-of-memory errors, minimize the size of the array fetches so that the amount of C memory allocated for selects is small. You can do this by setting the weblogic.oci.cacheRows property (a JDBC connection property) to a small number. For example,
       Properties props = new java.util.Properties();
       props.put("user",                   "scott");
       props.put("password",               "tiger");
       props.put("server",                 "DEMO" );
       props.put("weblogic.oci.cacheRows", "1"    );

       Class.forName("weblogic.jdbc.oci.Driver").newInstance();

       Connection conn =
          DriverManager.getConnection("jdbc:weblogic:oracle",  props);
- If the out of memory errors cease, it is likely that ResultSets are not being closed somewhere in your code. For more information, see Closing JDBC Objects. ### Codeset Support WebLogic supports Oracle codesets with the following considerations: If the user's NLS_LANG environment variable is not set, or if it is set to either US7ASCII or WE8ISO8859-1, the driver always operates in 8859-1. For more information, see Codeset Support in Using WebLogic jDriver for Oracle. ### Other Problems with Oracle on UNIX Check the threading model you are using. Green threads can conflict with the kernel threads used by OCI. When using Oracle drivers, WebLogic recommends that you use native threads. You can specify this by adding the -native flag when you start Java. If you are using the JVM for Solaris provided by Sun, you might want to switch to the JavaSoft JVM for Solaris, which WebLogic has found to be more stable. ## Thread-related Problems on UNIX On UNIX, two threading models are available: green threads and native threads. For more information, see JDK for the Solaris Operating Environment on the JavaSoft Web site. You can determine what type of threads you are using by checking the environment variable called THREADS_TYPE. If this variable is not set, you can check the shell script in your Java installation bin directory. Some of the problems are related to the implementation of threads in the JVM for each operating system. Not all JVMs handle operating-system specific threading issues equally well. Here are some hints to avoid thread-related problems: If you are using Oracle drivers, use native threads. There are also other limitations (above) regarding Oracle. Versions of the JDK prior to 1.1.6 have compatibility problems with OCI drivers. See Platform support for WebLogic jDriver JDBC drivers for your version of WebLogic Server. If you are using HP UNIX, upgrade to version 11.x, because there are compatibility issues with the JVM in earlier versions, such as HP UX 10.20. On HP UNIX, the new JDK does not append the green-threads library to the SHLIB_PATH. The current JDK can not find the shared library (.sl) unless the library is in the path defined by SHLIB_PATH. To check the current value of SHLIB_PATH, at the command line type:
       $ echo $SHLIB_PATH
Use the set or setenv command (depending on your shell) to append the WebLogic shared library to the path defined by the symbol SHLIB_PATH. For the shared library to be recognized in a location that is not part of your SHLIB_PATH, you will need to contact your system administrator. ## Closing JDBC Objects WebLogic also recommends -- and good programming practice dictates -- that you always close JDBC objects, like Connections, Statements, and ResultSets, in a finally block to make sure that your program executes efficiently. Here is a general example:
      try {
        Class.forName("weblogic.jdbc.oci.Driver").newInstance();
        Connection conn =
          DriverManager.getConnection("jdbc:weblogic:oracle:myserver",
                                      "scott",
                                      "tiger");
        Statement stmt = conn.createStatement();
        stmt.execute("select * from emp");
        ResultSet rs = stmt.getResultSet();

        // do work
        }
        catch (Exception e) {
          // deal with any exceptions appropriate
        }
        finally {
          try {rs.close();}
          catch (Exception rse) {}
          try {stmt.close();}
          catch (Exception sse) {}
          try {conn.close();
          catch (Exception cse) {}
        }

Copyright © 2000 BEA Systems, Inc. All rights reserved. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher. Last updated 01/07/2000