Specifies the transaction manager implementation that should be started. There is
no default value and this must be set. Generally,
com.atomikos.icatch.standalone.UserTransactionServiceFactory is the
value you should set.
Specifies the maximum timeout that can be allowed for transactions. Defaults to
300000. This means that calls to UserTransaction.setTransactionTimeout()
with a value higher than configured here will be max'ed to this value.
Specifies the maximum number of active transactions. Defaults to 50. A
negative value means infinite amount. You will get an IllegalStateException
with error message "Max number of active transactions reached" if you call
UserTransaction.begin() while there are already n concurrent transactions
running, n being this value.
maxActives - the max activities
public int getMaxActives()
public void setEnableLogging(boolean enableLogging)
Specifies if disk logging should be enabled or not. Defaults to true. It is useful
for JUnit testing, or to profile code without seeing the transaction manager's
activity as a hot spot but this should never be disabled on production or data
integrity cannot be guaranteed.
enableLogging - if logging is enabled
public boolean isEnableLogging()
public void setTransactionManagerUniqueName(String uniqueName)
Specifies the transaction manager's unique name. Defaults to the machine's IP
address. If you plan to run more than one transaction manager against one database
you must set this property to a unique value or you might run into duplicate
transaction ID (XID) problems that can be quite subtle (example:
http://fogbugz.atomikos.com/default.asp?community.6.2225.7). If multiple
instances need to use the same properties file then the easiest way to ensure
uniqueness for this property is by referencing a system property specified at VM
public void setSerialJtaTransactions(boolean serialJtaTransactions)
Specifies if subtransactions should be joined when possible. Defaults to true. When
false, no attempt to call XAResource.start(TM_JOIN) will be made for
different but related subtransactions. This setting has no effect on resource
access within one and the same transaction. If you don't use subtransactions then
this setting can be ignored.
serialJtaTransactions - if serial JTA transactions are supported
public boolean isSerialJtaTransactions()
public void setAllowSubTransactions(boolean allowSubTransactions)
public boolean isAllowSubTransactions()
public void setForceShutdownOnVmExit(boolean forceShutdownOnVmExit)
Specifies whether VM shutdown should trigger forced shutdown of the transaction
core. Defaults to false.
forceShutdownOnVmExit - if VM shutdown should be forced
public boolean isForceShutdownOnVmExit()
public void setDefaultMaxWaitTimeOnShutdown(long defaultMaxWaitTimeOnShutdown)
Specifies how long should a normal shutdown (no-force) wait for transactions to
complete. Defaults to Long.MAX_VALUE.
defaultMaxWaitTimeOnShutdown - the default max wait time on shutdown
Specifies the transactions log file base name. Defaults to tmlog. The
transactions logs are stored in files using this name appended with a number and
the extension .log. At checkpoint, a new transactions log file is
created and the number is incremented.
Specifies the directory in which the log files should be stored. Defaults to the
current working directory. This directory should be a stable storage like a SAN,
RAID or at least backed up location. The transactions logs files are as important
as the data themselves to guarantee consistency in case of failures.
public void setCheckpointInterval(long checkpointInterval)
Specifies the interval between checkpoints. A checkpoint reduces the log file size
at the expense of adding some overhead in the runtime. Defaults to 500.
checkpointInterval - the checkpoint interval
public long getCheckpointInterval()
public void setThreadedTwoPhaseCommit(boolean threadedTwoPhaseCommit)
Specifies whether or not to use different (and concurrent) threads for two-phase
commit on the participating resources. Setting this to true implies that
the commit is more efficient since waiting for acknowledgements is done in
parallel. Defaults to true. If you set this to false, then
commits will happen in the order that resources are accessed within the
threadedTwoPhaseCommit - if threaded two phase commits should be used