Linkar Suite 2.3.8

An EntryPoint can be configured with either or both of these session types: Permanent, or Temporal (also referred to as Temporary or On-Demand).

When the EP itself is started, it opens Permanent connections to the DBMS (as many as defined in the configuration) and keeps them active.

When the EntryPoint receives a request, Linkar SERVER assigns an available Database Session, created for this EP, to the operation.

If there are no free Linkar Database Sessions, Temporal sessions are started, one by one, up to the maximum defined in the configuration, or the maximum available Linkar licences.

If another Temporal session cannot be started, the transaction is queued.

The queue system used by the EntryPoint effectively manages server access from many Linkar Clients to a limited number of database ports. This is known as pooling, where the server maintains a dynamic pool of Database Sessions.

After a period of time defined for the EP (Inactivity seconds for disconnect), Temporal Database Sessions will go through a graceful wrapup, and ports and licences free up for later use.

Each EntryPoint has a series of common properties, and other properties that vary depending on the database and the type of connection to it.

See EntryPoint Configuration for further details.

Compare these two connection patterns:

This is how Linkar works:

Client executes a Login to an EntryPoint. A session ID is returned by Linkar SERVER.

Client executes first transaction. A connection is established by Linkar SERVER through the EP, queuing if necessary to get a free DBMS port. The transaction is processed, and the Database Session is set to OPEN:FREE.

Another client process is free to use that same Database Session.

Client executes another transaction. The exact same process takes place, using any open Database Session, opening a new one, or adding the transaction to the queue to wait for an existing Database Session to go to OPEN:FREE.

Client executes Logout. There is no action on the DBMS. The SERVER invalidates the Session ID.

As seen above, DBMS processes are not reserved by clients. Individual clients cannot attach and hold a DBMS process. This is also seen with Asynchronous transactions called from Linkar Clients. Async Transactions will not queue behind one another. Each transaction independently follows the above process, using, initializing, or waiting for a database port. As is possible with all such async processes, it is possible for async transactions to return out of request order.

This is how other tools work:

Client executes a Login. A DBMS process may be created, and is then reserved for the client.

Client executes transactions, DBMS process remains reserved.

Client executes Logout. DBMS process is released for other clients.

In this scenario, asynchronous processes still use the same DBMS connection. The results always come back in the order of request because they are actually processed synchronously on the server, in the order received, even though the results are processed asynchronously on the client.

Connections from a Linkar Client to an EntryPoint can be made as part of a Persistent Session, or as a Direct / Volatile transaction.

A Persistent Client Session is created when the client code uses CredentialsOptions for the initial Login. A unique SessionId is returned to a property on the LinkarClt object. This is transparently used in all subsequent exchanges until Logout. Credentials are not sent in on every transaction associated with a session. This helps to avoid authentication with each related transaction, thus reducing transaction time.

A Volatile transaction is performed using static/shared methods/functions. CredentialsOptions must be passed in as a part of each transaction from the client. No Session ID is returned. There is no object to maintain "state".

All Synchronous and Asynchronous instance methods on a LinkarClt instance are performed within the current Persistent Session.

All Synchronous and Asynchronous static methods on the LinkarClt class are performed as a Volatile transaction.

Both transaction types, Persistent and Volatile, use the same Queues, Database Session Pooling, and Database Port Usage as described above. Unlike other connectivity products, Linkar does not hold access to a Database Session for a Persistent Session. That is, all transactions go through the same process to access the EP and the DBMS, results are returned, and the Database Session is set to OPEN:FREE.

When a Persistent Session is used with an EP, the Client Sessions Monitor shows the Session ID. See the ID field in the screenshot in the Client Sessions section.

Volatile connections show the word VOLATILE in that field - and because these transactions are processed quickly the Client Sessions grid may or may not quickly flash a row to show the transaction occurred.

All REST API transactions are Volatile. This agrees with the HTTP protocol itself where every transaction to a web server is "atomic" and independent. With HTTP, multiple transactions are linked in applications using some sort of session ID, provided by a cookie, query token, or other mechanism. Applications using the REST API must manage state using normal design practices. (Look for the customVars argument on client functions, which is a "free text" string that can be passed between client and server to help establish a state mechanism.)

Permanent Database Sessions are always connected to avoid the time penalty of a login for any given client transaction.

Temporal Database Sessions are created when needed and logged-off when no longer needed.

Persistent Transactions use a "virtual login" with credentials on the initial connection, and a session ID for remaining transactions.

Volatile Transactions always perform a "virtual login" with credentials.

All Linkar Clients benefit from Linkar SERVER management of EntryPoints and their related Database Sessions, and maintenance of a queue to hold transactions until Database Sessions are available.