Databases Reference
In-Depth Information
Information that can be shared between requests is stored on the session and remains on
the server as long as the session is alive. The client application can end the session, and
the session manager can delete the session when time expires. Because a single connection
can work with multiple sessions, closing the connection doesn't automatically close the
session. The client application can reconnect and work with the same session. However,
the server can close a session if it is not in use for the timeout specified in the
IdleOrphanSessionTimeout server configuration property. It's not a good idea to rely on
the server to close a session. The system works more efficiently when the client applica-
tion deletes the session when it disconnects from the server.
Analysis Services assigns a unique name to the Session object so that the client applica-
tion can retrieve the name later (for example, using a DISCOVER_SESSIONS request) and use
it for subsequent requests.
If a client application doesn't create a new session when it establishes a connection,
Analysis Services creates a new Session object for it, but the object's lifetime is the same
as the lifetime of the request.
A session works with only one request at a time, except for commands to start a trace (for
information about traces, see Chapter 38) and requests to cancel execution of the previous
request (which we discuss later in this chapter).
A session executes requests sequentially. However, an Execute request can contain just one
command or group of commands wrapped in a Batch command. The server treats the
commands in a batch as a single unit for execution. A request that contains a Batch
command, as with other requests that contain a single command, executes sequentially.
However, commands contained within the Batch command can execute either sequen-
tially or in parallel, depending on the definition of the Batch command. (For more infor-
mation, see the “ Batch Command” section later in this chapter.)
In addition to the Session object that services a group of commands, Analysis Services
creates an Execution Context object that contains the information and resources required
to execute a single request. The lifetime of the Execution Context object is the same as
the lifetime of the request. After the request is completed, the Execution Context is
released and the resources are returned to the system.
Server State Management
Commands that arrive to Analysis Services can be divided into two categories:
.
Commands that don't change the state of the server, such as MDX requests for data
.
Commands that do change the state of objects on the server, such as Create , Alter ,
Delete , Process , and many other commands
Commands that change the objects of a database execute atomically: After the command
successfully executes, the object of the database it worked with transforms into a new
state, and all subsequent commands work with the new version of the object. If a
command fails or is canceled, all the changes to the object roll back. The object remains
Search WWH ::




Custom Search