...
File property name | Configuration property name | Default value | Description |
|---|---|---|---|
bitronix.tm.serverId | The machine's IP address but that's unsafe for production usage | an a stable ASCII ID string that must uniquely identify this TM instance. It must not exceed 51 characters or it will be truncated. | |
bitronix.tm.2pc.async | false | Should two phase commit be executed asynchronously? Asynchronous two phase commit will improve 2PC execution time when there are many resources enlisted in transactions but can be very CPU intensive when used on JDK 1.4 without the java.util.concurrent backport implementation available on the classpath. It also makes debugging more complex. See here for more details. | |
bitronix.tm.2pc.warnAboutZeroResourceTransactions | true | Should transactions executed without a single enlisted resource result in a warning or not? Most of the time transactions executed with no enlisted resource reflect a bug or a mis-configuration somewhere. | |
| bitronix.tm.2pc.debugZeroResourceTransactions | debugZeroResourceTransaction | false | Should creation and commit call stacks of transactions executed without a single enlisted resource tracked and logged or not? This is a companion to warnAboutZeroResourceTransaction where the transaction creation and commit call stacks could help you identify the culprit code. |
bitronix.tm.disableJmx | false | The transaction manager registers objects in the JMX registry by default if available. Set this to true to never register JMX objects. | |
bitronix.tm.jndi.userTransactionName | java:comp/UserTransaction | The name under which the transaction manager will be bound in the internal JNDI provider. | |
| bitronix.tm.allowMultipleLrc | allowMultipleLrc | false | Should the transaction manager allow multiple LRC resources to be enlisted into the same transaction? Having multiple LRC resources participate in a transaction gives up the recovery guarantee but sometimes is useful in development mode. |
bitronix.tm.currentNodeOnlyRecovery | true | Set this to true if you run multiple instances of the transaction manager on the same JMS and JDBC resources to avoid the recovery process to try to recover transactions started by another node. See here for more details. |
...