Session
Programs use sessions to insulate data grid operations within program threads and to group operations into atomic transactions.
Sessions and Threads
It is good practice to create a separate session for each program thread that accesses the data grid.
Programs must use sessions in a thread-safe way. That is, two threads must not simultaneously access the same session. Violating this constraint can yield unpredictable results.
Sessions and Transactions
Each session can be either transacted or non-transacted. Programs determine this semantic property when creating each session.
In a transacted session, all GET, PUT, UPDATE, and DELETE operations occur within a transaction, which is bound to the session. The session implicitly starts the transaction. Programs explicitly call the session's commit and rollback methods. (As these methods complete, they automatically start a new transaction in the session.)
If a program operates within several open transactions simultaneously, use a separate session and thread for each transaction.
In a transacted session, all operations are performed atomically when the session calls the commit method (tibdgSession_Commit or the equivalent in the Java API). If errors occur that require the transaction to be canceled, the application might call the rollback method (tibdgSession_Rollback) to undo all the operations included in the transaction.
In a non-transacted session, one operation is performed at a time as and when they are requested. The GET, PUT, UPDATE, and DELETE operations are immediate: that is, when the method completes, the effect of the operation is also complete.
However, operations in a transacted session can block operations in a non-transacted session. For further explanation, see Transaction Isolation.
Only GET, PUT, UPDATE, and DELETE operations are affected by a transacted session, the corresponding commit, and rollback APIs. Other commands such as iterators, queries, and DDL updates do not have different behavior when running on a transacted session versus a non-transacted session.
Transaction Workflow Session Timeout Options
The transaction activity timeout is used to resolve deadlocks and detect the applications that have stopped responding.
The per-session transaction activity timeout is used to specify a different activity timeout for a single session. You can add the timeout value to a transaction workflow when creating a session by adding the TIBDG_SESSION_PROPERTY_DOUBLE_TRANSACTION_TIMEOUT property. The value of this property is in seconds.
For example, if a transaction requires many keys to assemble and cannot complete in 30 seconds, which is the default interval, use this property to specify the time that the data grid waits before canceling the transaction.
In addition, you can specify the maximum allowed per-session transaction activity timeout for a grid by using the txn_activity_tmo_max configuration option.
If a transaction timeout has expired, it might be canceled. If the application has not yet called the commit method and a grid node fails, the running transactions might be canceled before the per-session timeout. If the commit method returns a timeout error value, the transactions might not have been completed. Such a scenario must be handled in the applications.
Sessions and Defining Tables
After a session has been created, it can be used to define tables programmatically. For more information, see "Defining a Table by Using SQL DDL Commands" in TIBCO ActiveSpaces® - Enterprise Edition Administration.