Transaction Size, Memory, and Performance

There is no fixed limit on the number of commands that can be issued under a single transaction. However, there are memory size and performance constraints on the size of a transaction. The memory used by a deleted object is not freed until the transaction is committed. Thus, an application that deletes a large number of tables or a very large table and then recreates them under the same transaction might find that the TIBCO Patterns server runs out of memory because it is holding two copies of all of these tables. The same is true if a very large number of record operations are performed under the same transaction.

A performance impact is associated with very large transactions. Operations on thesauri, character maps or Learn models are generally not a concern as it is very rare that hundreds, much fewer thousands of these operations are performed in a single transaction. However it is not unusual for hundreds of thousands of records to be updated at once. Performing hundreds of thousands of individual record operations in a single transaction significantly impacts performance and memory usage. If a very large number of records are to be added, use a bulk (fast) load. This avoids the creation of tracking information on individual records, which saves both time and memory. (But this locks the entire table, excluding other transactions from updating records.) Use explicit transactions only when necessary and keep them as small as possible. As a rule, limit non-bulk record operations to about 64K – 100K records in a single transaction. The TIBCO Patterns server handles far larger numbers, but there might be significant performance impacts.

There is no fixed limit on how long an explicit transaction can be held open. However, open transactions can delay administrative operations and the server's internal bookkeeping. Explicit transactions should be committed or rolled-back as quickly as possible.

There is no fixed limit on the number of explicit transactions. However, keeping a large number of explicit transactions impacts both memory usage and server speed.