Java DB

Apache Derby

Derby Developer's Guide

Derby Getting Started
Derby Reference Manual
Derby Developer's Guide
Derby Performance Tuning
Derby Server and Admin Guide
Derby Tools and Utilities
Derby Developer's Guide
-After installing
-Upgrades
-JDBC applications and Derby basics
-Application development overview
-Derby embedded basics
-Derby JDBC driver
-Derby JDBC database connection URL
-Derby system
-A Derby database
-Connecting to databases
-Working with the database connection URL attributes
-Using in-memory databases
-Working with Derby properties
-Deploying Derby applications
-Deployment issues
-Creating Derby databases for read-only use
-Loading classes from a database
-Derby server-side programming
-Programming database-side JDBC routines
-Programming trigger actions
-Programming Derby-style table functions
-Programming user-defined types
-Controlling Derby application behavior
-The JDBC connection and transaction model
-Result set and cursor mechanisms
-Locking, concurrency, and isolation
-Working with multiple connections to a single database
-Working with multiple threads sharing a single connection
-Working with database threads in an embedded environment
-Working with Derby SQLExceptions in an application
-Using Derby as a J2EE resource manager
-Derby and Security
-Configuring security for your environment
-Working with user authentication
-Users and authorization identifiers
-User authorizations
-Encrypting databases on disk
-Signed jar files
-Notes on the Derby security features
-User authentication and authorization examples
-Running Derby under a security manager
-Developing tools and using Derby with an IDE
-SQL tips
-Localizing Derby
-Derby and standards

 

Programming applications to handle deadlocks

When you configure your system for deadlock and lockwait timeouts and an application could be chosen as a victim when the transaction times out, you should program your application to handle them.

To do this, test for SQLExceptions with SQLStates of 40001 (deadlock timeout) or 40XL1 or 40XL2 (lockwait timeout).

In the case of a deadlock you might want to re-try the transaction that was chosen as a victim. In the case of a lock wait timeout, you probably do not want to do this right away.

The following code is one example of how to handle a deadlock timeout.

/// if this code might encounter a deadlock, 
// put the whole thing in a try/catch block
// then try again if the deadlock victim exception 
// was thrown
try {
    s6.executeUpdate(
         "UPDATE employee " +
         "SET bonus = 625 "
         "WHERE empno='000150'");
    s6.executeUpdate("UPDATE project " +
         "SET respemp = '000150' " +
         "WHERE projno='IF1000'");
} 
// note: do not catch such exceptions in database-side methods; 
// catch such exceptions only at the outermost level of 
// application code. 
// See Database-side JDBC routines and SQLExceptions.  
catch (SQLException se) { 
    if (se.getSQLState().equals("40001")) { 
        // it was chosen as a victim of a deadlock. 
        // try again at least once at this point. 
        System.out.println( "Will try the transaction again."); 
        s6.executeUpdate("UPDATE employee " + 
        "SET bonus = 625 " + 
        "WHERE empno='000150'"); 
        s6.executeUpdate("UPDATE project " + 
        "SET respemp = 000150 " + 
        "WHERE projno='IF1000'"); 
    } 
    else throw se; 
}
 

javadb@jdbcurl.com