The PER_TRANSACTION memory duration

A PER_TRANSACTION memory pool can be associated with either of the following:
  • Each client transaction

    If the UDR makes a PER_TRANSACTION allocation during a client transaction, the database server uses memory from the PER_TRANSACTION memory pool. The way that a transaction begins and ends depends on whether the database is ANSI-compliant and whether it uses logging. (For more information, see Transaction management.)

  • A cursor started in a transaction

    Statements within a cursor are considered a type of transaction. If the UDR makes a PER_TRANSACTION allocation within a cursor, the database server allocates memory from a special PER_CURSOR memory pool, which lasts from the open to the close of the cursor.

    The PER_CURSOR memory duration is for internal use only. However, you might see information about the PER_CURSOR memory pool in the output of onstat -g mem. The database server creates a PER_CURSOR memory pool for each cursor in a transaction.

When a C UDR allocates PER_TRANSACTION memory, this memory is available to all routine instances that execute before the current transaction closes. The database server reclaims any PER_TRANSACTION shared memory in the memory context in either of the following situations:
  • When the current transaction ends (with commit or rollback)
    • If SQL statements execute in an explicit transaction, PER_TRANSACTION memory remains allocated until all statements in the transaction complete.
    • If each SQL statement is a separate transaction, the database server deallocates PER_TRANSACTION and PER_STMT_EXEC memory at the same time.

    If a hold cursor is open when the transaction ends, the database server does not deallocate PER_TRANSACTION memory. However, it does deallocate PER_TRANSACTION memory whenever a hold cursor closes.

  • When the cursor closes

    If the UDR allocated PER_TRANSACTION memory within a cursor, the database server reclaims this memory when the cursor closes.

Tip: An EXECUTE PROCEDURE statement does not create an implicit transaction. If EXECUTE PROCEDURE is not already part of an explicit transaction, the UDR that it calls can use a BEGIN WORK and COMMIT WORK (or ROLLBACK WORK) to specify a transaction. For more information, see Transaction management.

At this time, the database server does not reclaim any memory in the memory context with a duration higher than PER_TRANSACTION.

The PER_TRANSACTION memory duration is useful for the following tasks:
  • Cooperating UDRs in user-defined access methods (created with the HCL Informix® VTI and VII interfaces)
  • Committing and rolling back external resources (such as files and smart large objects)
  • Allocating memory within an end-of-transaction callback (if you have information to pass to the callback)
  • Allocating data type structures that need to persist during an implicit or explicit transaction

Allocate PER_TRANSACTION memory as named memory because this memory requires locking. To access it, a C UDR must know the name of the memory and it must be within the scope of the transaction. Such a UDR can explicitly free this memory with the mi_named_free() function. However, consider PER_TRANSACTION memory as permanent to the current transaction. For more information, see Manage named memory.

No DataBlade® API constructor function allocates its data type structure with a memory duration of PER_TRANSACTION.