299 lines
21 KiB
HTML
299 lines
21 KiB
HTML
<?xml version="1.0" encoding="utf-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<meta name="dc.language" scheme="rfc1766" content="en-us" />
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
|
<!-- US Government Users Restricted Rights -->
|
|
<!-- Use, duplication or disclosure restricted by -->
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
|
<meta name="dc.date" scheme="iso8601" content="2005-09-19" />
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
|
<meta name="security" content="public" />
|
|
<meta name="Robots" content="index,follow"/>
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
|
<meta name="keywords" content="application requester,
|
|
distributed relational database, application server,
|
|
distributed relational database architecture (DRDA),
|
|
DRDA (Distributed Relational Database Architecture), in DRDA, package,
|
|
remote unit of work, connection states, CONNECT (Type 2) statement, SQL,
|
|
connection, distributed unit of work,
|
|
application-directed distributed unit of work, SQL connection, states,
|
|
current connection state, dormant connection state, held connection state,
|
|
release-pending connection state, activation group, connected state,
|
|
unconnected state, data representation, data representation considerations" />
|
|
<title>Distributed relational database</title>
|
|
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
|
|
<link rel="stylesheet" type="text/css" href="ic.css" />
|
|
</head>
|
|
<body>
|
|
<a id="Top_Of_Page" name="Top_Of_Page"></a><!-- Java sync-link -->
|
|
<script language = "Javascript" src = "../rzahg/synch.js" type="text/javascript"></script>
|
|
|
|
|
|
<a name="ch1drda"></a>
|
|
<h2 id="ch1drda"><a href="rbafzmst02.htm#ToC_65">Distributed relational database</a></h2><a id="idx195" name="idx195"></a><a id="idx196" name="idx196"></a><a id="idx197" name="idx197"></a><a id="idx198" name="idx198"></a><a id="idx199" name="idx199"></a><a id="idx200" name="idx200"></a><a id="idx201" name="idx201"></a><a id="idx202" name="idx202"></a>
|
|
<p>A <span class="italic">distributed relational database</span> consists of a
|
|
set of tables and other objects that are spread across different but interconnected
|
|
computer systems or logical partitions on the same computer system. Each computer
|
|
system has a relational database manager that manages the tables in its environment.
|
|
The database managers communicate and cooperate with each other in a way that
|
|
allows a database manager to execute SQL statements on another computer system.</p>
|
|
<p>Distributed relational databases are built on formal requester-server protocols
|
|
and functions. An <span class="italic">application requester</span> supports the
|
|
application end of a connection. It transforms a database request from the
|
|
application into communication protocols suitable for use in the distributed
|
|
database network. These requests are received and processed by an <span class="italic">application server</span> at
|
|
the other end of the connection.<sup class="fn"><a id="wq50" name="wq50" href="rbafzmstch2drda.htm#wq51">11</a></sup> Working together, the application requester
|
|
and application server handle the communication and location considerations so that
|
|
the application is isolated from these considerations and can operate as if
|
|
it were accessing a local database. A simple distributed relational database
|
|
environment is illustrated in <a href="rbafzmstch2drda.htm#simpdis">Figure 8</a>.</p>
|
|
<a name="simpdis"></a>
|
|
<div class="fignone" id="simpdis"><span class="figcap">Figure 8. A Distributed Relational Database Environment</span>
|
|
<div class="mmobj">
|
|
<img src="rv2f977.gif" alt="A Distributed Relational Database Environment. An SQL Program (Application requester) in Los Angeles connects to an SQL package (Application server) in Dallas." /></div></div>
|
|
<p>For more information about Distributed Relational
|
|
Database Architecture™ (DRDA®) communication protocols, see <a href="http://www.opengroup.org/dbiop" target="_blank">Open Group Publications: DRDA Vol. 1: Distributed Relational
|
|
Database Architecture (DRDA)</a>
|
|
<img src="www.gif" alt="Link outside of Information Center" /></p>
|
|
<a name="wq52"></a>
|
|
<h3 id="wq52"><a href="rbafzmst02.htm#ToC_66">Application servers</a></h3>
|
|
<p>An activation group must be connected to the application server of a
|
|
database manager before SQL statements can be executed.</p>
|
|
<p>A <span class="italic">connection</span> is an association between
|
|
an activation group and a local or remote application server. A connection is also
|
|
known as a session or an SQL session. Connections are managed by the application.
|
|
The CONNECT statement can be used to establish a connection to an application server and
|
|
make that application server the current server of the activation group.</p><a id="idx203" name="idx203"></a>
|
|
<p>An application server can be local to, or remote from, the environment where the
|
|
activation group is started. (An application server is present, even when distributed
|
|
relational databases are not used.) This environment includes a local directory
|
|
that describes the application servers that can be identified in a CONNECT statement.
|
|
For more information about the directory, see the relational database folders
|
|
in iSeries™ Navigator or the directory commands (ADDRDBDIRE, CHGRDBDIRE,
|
|
DSPRDBDIRE, RMVRDBDIRE, and WRKRDBDIRE) in the following iSeries Information Center topics:</p>
|
|
<ul>
|
|
<li><a href="../sqlp/rbafykickoff.htm">SQL Programming</a></li>
|
|
<li><a href="../ddp/rbal1kickoff.htm">Distributed Database Programming</a></li>
|
|
<li><a href="../rbam6/rbam6clmain.htm">CL commands</a></li></ul>
|
|
<p>To execute a static SQL statement that references tables or views, an application server uses
|
|
the bound form of the statement. This bound statement is taken from a package
|
|
that the database manager previously created through a bind operation. The
|
|
appropriate package is determined by the combination of: </p>
|
|
<ul>
|
|
<li>The name of the package specified by the SQLPKG parameter on the CRTSQLxxx
|
|
commands. See the <a href="../rzajp/rzajpkickoff.htm">Embedded SQL Programming</a> book for
|
|
a description of the CRTSQLxxx commands.</li>
|
|
<li>The internal consistency token that makes certain the package and program
|
|
were created from the same source at the same time.</li></ul>
|
|
<p>A DB2® relational database product may support a feature that is not supported
|
|
by the version of the DB2 UDB product that is connecting to the application server.
|
|
Some of these features are product-specific, and some are shared by more than
|
|
one product.</p>
|
|
<p>For the most part, an application can use the statements and clauses that
|
|
are supported by the database manager of the application server to which it is currently
|
|
connected, even though that application is running via the application requester
|
|
of a database manager that does not support some of those statements and clauses.
|
|
Restrictions are listed in <a href="rbafzmstdiftab.htm#diftab">Appendix B. Characteristics of SQL statements</a>.</p>
|
|
<a name="con2j"></a>
|
|
<h3 id="con2j"><a href="rbafzmst02.htm#ToC_67">CONNECT (Type 1) and CONNECT (Type 2)</a></h3>
|
|
<p>There are two types of CONNECT statements with the same syntax but different
|
|
semantics: </p>
|
|
<ul>
|
|
<li>CONNECT (Type 1) is used for remote unit of work. See <a href="rbafzmstconj1.htm#conj1">CONNECT (Type 1)</a>.</li>
|
|
<li>CONNECT (Type 2) is used for distributed unit of work. See <a href="rbafzmstcon2t.htm#con2t">CONNECT (Type 2)</a>.</li></ul>
|
|
<p>See <a href="rbafzmstdiftab2.htm#rcncdif">CONNECT (Type 1) and CONNECT (Type 2) differences</a> for a summary of the differences.</p>
|
|
<a name="cmrwj"></a>
|
|
<h3 id="cmrwj"><a href="rbafzmst02.htm#ToC_68">Remote unit of work</a></h3><a id="idx204" name="idx204"></a><a id="idx205" name="idx205"></a>
|
|
<p>The <span class="italic">remote unit of work</span> facility provides for the
|
|
remote preparation and execution of SQL statements. An activation group at
|
|
computer system A can connect to an application server at computer system B. Then,
|
|
within one or more units of work, that activation group can execute any number
|
|
of static or dynamic SQL statements that reference objects at B. After ending
|
|
a unit of work at B, the activation group can connect to an application server at
|
|
computer system C, and so on.</p>
|
|
<p>Most SQL statements can be remotely prepared and executed with the following
|
|
restrictions: </p>
|
|
<ul>
|
|
<li>All objects referenced in a single SQL statement must be managed by the
|
|
same application server.</li>
|
|
<li>All of the SQL statements in a unit of work must be executed by the same application server.</li></ul>
|
|
<a name="ruwcnst"></a>
|
|
<h4 id="ruwcnst">Remote unit of work connection management</h4><a id="idx206" name="idx206"></a>
|
|
<p>An activation group is in one of three states at any time: </p>
|
|
<ul class="simple">
|
|
<li>Connectable and connected</li>
|
|
<li>Unconnectable and connected</li>
|
|
<li>Connectable and unconnected</li></ul>
|
|
<p>The following diagram shows the state transitions:</p>
|
|
<a name="rcntyp2"></a>
|
|
<div class="fignone" id="rcntyp2"><span class="figcap">Figure 9. Remote Unit of Work Activation Group Connection State Transition</span>
|
|
<div class="mmobj">
|
|
<img src="rbal3504.gif" alt="Remote Unit of Work Activation Group Connection State Transition. Graphic described in text." /></div></div>
|
|
<p>The initial state of an activation group is <span class="italic">connectable</span> and <span class="italic">connected</span>. The application server to which the activation
|
|
group is connected is determined by the RDB parameter on the CRTSQLxxx and
|
|
STRSQL commands and may involve an implicit CONNECT operation. An implicit
|
|
CONNECT operation cannot occur if an implicit or explicit CONNECT operation
|
|
has already successfully or unsuccessfully occurred. Thus, an activation group
|
|
cannot be implicitly connected to an application server more than once.</p>
|
|
<a name="wq53"></a>
|
|
<h5 id="wq53">The connectable and connected state</h5>
|
|
<p>An activation group is connected to an application server and CONNECT statements
|
|
can be executed. The activation group enters this state when it completes
|
|
a rollback or successful commit from the unconnectable and connected state,
|
|
or a CONNECT statement is successfully executed from the connectable and unconnected
|
|
state.</p>
|
|
<a name="wq54"></a>
|
|
<h5 id="wq54">The unconnectable and connected state</h5>
|
|
<p>An activation group is connected to an application server, but a CONNECT statement
|
|
cannot be successfully executed to change application servers. The activation group
|
|
enters this state from the connectable and connected state when it executes
|
|
any SQL statement other than CONNECT, COMMIT, or ROLLBACK.</p>
|
|
<a name="wq55"></a>
|
|
<h5 id="wq55">The connectable and unconnected state</h5>
|
|
<p>An activation group is not connected to an application server. The only SQL statement
|
|
that can be executed is CONNECT.</p>
|
|
<p>The activation group enters this state when: </p>
|
|
<ul>
|
|
<li>The connection was previously released and a successful COMMIT is executed.</li>
|
|
<li>The connection is disconnected using the SQL DISCONNECT statement.</li>
|
|
<li>The connection was in a connectable state, but the CONNECT statement was
|
|
unsuccessful.</li></ul><a id="idx207" name="idx207"></a><a id="idx208" name="idx208"></a>
|
|
<p>Consecutive CONNECT statements can be executed successfully because CONNECT
|
|
does not remove the activation group from the connectable state. A CONNECT
|
|
to the application server to which the activation group is currently connected is
|
|
executed like any other CONNECT statement. CONNECT cannot execute successfully
|
|
when it is preceded by any SQL statement other than CONNECT, COMMIT, DISCONNECT,
|
|
SET CONNECTION, RELEASE, or ROLLBACK (unless running with COMMIT(*NC)). To
|
|
avoid an error, execute a commit or rollback operation before a CONNECT statement
|
|
is executed.</p>
|
|
<a name="adduwmg"></a>
|
|
<h3 id="adduwmg"><a href="rbafzmst02.htm#ToC_73">Application-directed distributed unit of work</a></h3>
|
|
<p>The <span class="italic">application-directed distributed unit of work facility</span> also provides for the remote preparation and execution of SQL statements
|
|
in the same fashion as remote unit of work. Like remote unit of work, an activation
|
|
group at computer system A can connect to an application server at computer system
|
|
B and execute any number of static or dynamic SQL statements that reference
|
|
objects at B before ending the unit of work. All objects referenced in a single
|
|
SQL statement must be managed by the same application server. However, unlike remote
|
|
unit of work, any number of application servers can participate in the same unit of
|
|
work. A commit or rollback operation ends the unit of work.</p>
|
|
<p>Distributed unit of work is fully supported for APPC and TCP/IP connections.</p>
|
|
<a name="jac3"></a>
|
|
<h4 id="jac3">Application-directed distributed unit of work connection management</h4><a id="idx209" name="idx209"></a><a id="idx210" name="idx210"></a><a id="idx211" name="idx211"></a><a id="idx212" name="idx212"></a>
|
|
<p>At any time: </p>
|
|
<ul>
|
|
<li>An activation group is always in the <span class="italic">connected</span> or <span class="italic">unconnected</span> state and has a set of zero or more connections.
|
|
Each connection of an activation group is uniquely identified by the name
|
|
of the application server of the connection.</li>
|
|
<li>An SQL connection is always in one of the following states:
|
|
<ul>
|
|
<li> and held</li>
|
|
<li> and release-pending</li>
|
|
<li>Dormant and held</li>
|
|
<li>Dormant and release-pending</li></ul></li></ul>
|
|
<a name="wq56"></a>
|
|
<h5 id="wq56">Initial state of an activation group</h5>
|
|
<p>An activation group is initially in the connected state and has exactly
|
|
one connection. The initial state of a connection is <span class="italic">current
|
|
and held</span>.</p>
|
|
<p>The following diagram shows the state transitions:</p>
|
|
<a name="rcntyps"></a>
|
|
<div class="fignone" id="rcntyps"><span class="figcap">Figure 10. Application-Directed Distributed Unit of Work Connection and Activation Group Connection State Transitions</span>
|
|
<div class="mmobj">
|
|
<img src="rbal3503.gif" alt="Application-Directed Distributed Unit of Work Connection and Activation Group Connection State Transitions. Graphic described in text." /></div></div>
|
|
<a name="wq57"></a>
|
|
<h4 id="wq57">Connection states</h4><a id="idx213" name="idx213"></a><a id="idx214" name="idx214"></a><a id="idx215" name="idx215"></a><a id="idx216" name="idx216"></a><a id="idx217" name="idx217"></a>
|
|
<p>If an application process successfully executes a CONNECT statement: </p>
|
|
<ul>
|
|
<li>The current connection is placed in the dormant state and held state.</li>
|
|
<li>The server name is added to the set of connections and the new connection
|
|
is placed in the current and held state.</li></ul><p class="indatacontent"> If the server name is already in the set of existing connections of
|
|
the activation group, an error is returned.</p>
|
|
<p>A connection in the dormant state is placed in the current state using
|
|
the SET CONNECTION statement. When a connection is placed in the current state,
|
|
the previous current connection, if any, is placed in the dormant state. No
|
|
more than one connection in the set of existing connections of an activation
|
|
group can be current at any time. Changing the state of a connection from
|
|
current to dormant or from dormant to current has no effect on its held or
|
|
release-pending state.</p>
|
|
<p>A connection is placed in the release-pending state by the RELEASE statement.
|
|
When an activation group executes a commit operation, every release-pending
|
|
connection of the activation group is ended. Changing the state of a connection
|
|
from held to release-pending has no effect on its current or dormant state.
|
|
Thus, a connection in the release-pending state can still be used until the
|
|
next commit operation. There is no way to change the state of a connection
|
|
from release-pending to held.</p>
|
|
<a name="wq58"></a>
|
|
<h4 id="wq58">Activation group connection states</h4><a id="idx218" name="idx218"></a><a id="idx219" name="idx219"></a><a id="idx220" name="idx220"></a>
|
|
<p>A different application server can be established by the explicit or implicit execution
|
|
of a CONNECT statement. The following rules apply: </p>
|
|
<ul>
|
|
<li>An activation group cannot have more than one connection to the same application server at
|
|
the same time.</li>
|
|
<li>When an activation group executes a SET CONNECTION statement, the specified
|
|
location name must be an existing connection in the set of connections of
|
|
the activation group.</li>
|
|
<li>When an activation group executes a CONNECT statement, the specified server
|
|
name must not be an existing connection in the set of connections of the activation
|
|
group.</li></ul>
|
|
<p><span class="bold">If an activation group has a current connection</span>,
|
|
the activation group is in the <span class="italic">connected</span> state. The
|
|
CURRENT SERVER special register contains the name of the application server of the
|
|
current connection. The activation group can execute SQL statements that refer
|
|
to objects managed by that application server.</p>
|
|
<p>An activation group in the unconnected state enters the connected state
|
|
when it successfully executes a CONNECT or SET CONNECTION statement.</p>
|
|
<p><span class="bold">If an activation group does not have a current connection</span>, the activation group is in the <span class="italic">unconnected</span> state.
|
|
The CURRENT SERVER special register contents are equal to blanks. The only
|
|
SQL statements that can be executed are CONNECT, DISCONNECT, SET CONNECTION,
|
|
RELEASE, COMMIT, and ROLLBACK.</p>
|
|
<p>An activation group in the connected state enters the unconnected state
|
|
when its current connection is intentionally ended or the execution of an
|
|
SQL statement is unsuccessful because of a failure that causes a rollback
|
|
operation at the current server and loss of the connection. Connections are
|
|
intentionally ended when an activation group successfully executes a commit
|
|
operation and the connection is in the release-pending state, or when an application
|
|
process successfully executes the DISCONNECT statement.</p>
|
|
<a name="wq59"></a>
|
|
<h4 id="wq59">When a connection is ended</h4>
|
|
<p>When a connection is ended, all resources that were acquired by the activation
|
|
group through the connection and all resources that were used to create and
|
|
maintain the connection are deallocated. For example, if application process
|
|
P has placed the connection to application server X in the release-pending state, all cursors
|
|
of P at X will be closed and deallocated when the connection is ended during
|
|
the next commit operation.</p>
|
|
<p>A connection can also be ended as a result of a communications failure
|
|
in which case the activation group is placed in the unconnected state. All
|
|
connections of an activation group are ended when the activation group ends.</p>
|
|
<a name="drconsider"></a>
|
|
<h3 id="drconsider"><a href="rbafzmst02.htm#ToC_79">Data representation considerations</a></h3><a id="idx221" name="idx221"></a><a id="idx222" name="idx222"></a>
|
|
<p>Different systems represent data in different ways. When data is moved
|
|
from one system to another, data conversion must sometimes be performed. Products
|
|
supporting DRDA will automatically perform any necessary conversions at the receiving
|
|
system.</p>
|
|
<p>With numeric data, the information needed to perform the conversion is
|
|
the data type and the sending system's environment type. For example,
|
|
when a floating-point variable from a DB2 UDB for iSeries application requester is assigned
|
|
to a column of a table at an z/OS application server, the number is converted from
|
|
IEEE format to System/370* format.</p>
|
|
<p>With character and graphic data, the data type and the environment type
|
|
of the sending system are not sufficient. Additional information is needed
|
|
to convert character and graphic strings. String conversion depends on both
|
|
the coded character set of the data and the operation to be done with that
|
|
data. String conversions are done in accordance with the IBM® Character Data
|
|
Representation Architecture (CDRA). For more information about character conversion,
|
|
refer to the book <cite>Character Data Representation Architecture Level 1 Reference,</cite> SC09-1390.</p>
|
|
<hr /><div class="fnnum"><a id="wq51" name="wq51" href="rbafzmstch2drda.htm#wq50">11</a>.</div>
|
|
<div class="fntext">This is also known as a <span class="italic">an application server</span>.</div>
|
|
<br />
|
|
<hr /><br />
|
|
[ <a href="#Top_Of_Page">Top of Page</a> | <a href="rbafzmstsortsequence.htm">Previous Page</a> | <a href="rbafzmstsqlelem.htm">Next Page</a> | <a href="rbafzmst02.htm#wq1">Contents</a> |
|
|
<a href="rbafzmstindex.htm#index">Index</a> ]
|
|
|
|
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
|
|
</body>
|
|
</html>
|