JNI transactional programming

The Java Native Interface (JNI) is transactional if the JNI APIs are called in the context of a transaction. If there is no current transaction, no transactional behavior occurs.

This means the following when JNI is used in a transaction:

All JNI code that accesses transactional resources in a transaction must check for deadlock exceptions after each call and return to the caller. This is done the same way as all other exception handling in JNI.

Example 4.19. Transactional JNI programming

static void JNICALL
Java_com_kabira_platform_someClass_someNative(JNIEnv *env, jclass)
{
     doSomeWork(env);

     //
     //     Check for an exception - this could be a deadlock
     //
     if (env->ExceptionCheck())
     {
           // propagate exception to caller
          return;
     }

     doMoreWork(env);

     if (env->ExceptionCheck())
     ...
}

[Warning]

Accessing an object that requires a transaction without an active transaction is not detected. This programming error will cause unpredictable behavior in the application because no transaction isolation guarantees are made for the JNI accesses.

All native resources such as file descriptors, sockets, or heap memory are always non-transactional.

Transaction notifiers can be used to support transaction safe management of non-transactional resources. The onPrepare, onCommit, and onRollback methods can be implemented as native methods to perform this management. See the section called “Notifiers”.