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 memory allocated, read, modified, or deleted using JNI APIs is transactional - it is logged and locked.
the current transactional isolation is provided for field data.
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()) ... }
![]() | |
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”.