Open topic with navigation

TIBCO ActiveSpaces® 4.8.0

# 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 nontransacted session, 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.

## 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® Administration.

Copyright © 2009-2022. Cloud Software Group, Inc. All Rights Reserved.