ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzakj_5.4.0.1/rzakjthreadscoped.htm

89 lines
5.8 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 lang="en-us" xml:lang="en-us">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<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="DC.Type" content="concept" />
<meta name="DC.Title" content="SQL server mode and thread-scoped transactions for commitment control" />
<meta name="abstract" content="Commitment definitions with job-scoped locks are normally scoped to an activation group." />
<meta name="description" content="Commitment definitions with job-scoped locks are normally scoped to an activation group." />
<meta name="DC.Relation" scheme="URI" content="rzakjconcepts.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakjxatransaction.htm" />
<meta name="DC.Relation" scheme="URI" content="../apis/qwtchgjb.htm" />
<meta name="DC.Relation" scheme="URI" content="../cli/rzadpsqlapd.htm" />
<meta name="DC.Relation" scheme="URI" content="../cli/rzadpstartingservermode.htm" />
<meta name="DC.Relation" scheme="URI" content="../cli/rzadprestrictions.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 2004, 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2004, 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="rzakjthreadscoped" />
<meta name="DC.Language" 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. -->
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
<link rel="stylesheet" type="text/css" href="./ic.css" />
<title>SQL server mode and thread-scoped transactions for commitment control</title>
</head>
<body id="rzakjthreadscoped"><a name="rzakjthreadscoped"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">SQL server mode and thread-scoped transactions for commitment control</h1>
<div><p>Commitment definitions with job-scoped locks are normally scoped
to an activation group.</p>
<p>If a job is multithreaded, all threads in the job
have access to the commitment definition and changes made for a particular
transaction can be spread across multiple threads. That is, all threads whose
programs run in the same activation group participate in a single transaction.</p>
<p>There are cases where it is desirable for transactional work to be scoped
to the thread, rather than an activation group. In other words, each thread
has its own commitment definition and transactional work for each commitment
definition is independent of work performed in other threads.</p>
<p>This is supported by DB2 Universal Database™ (UDB) for iSeries™ by
using the Change Job (QWTCHGJB) API to change the job to run in SQL server
mode. When an SQL connection is requested in SQL server mode, it is routed
to a separate job. All subsequent SQL operations that are performed for that
connection are also routed to that job. When the connection is made, completion
message SQL7908 is sent to the SQL server mode job's job log indicating which
job the SQL requests are being routed to. The commitment definition is owned
by the job that is indicated in this message. If errors occur, it might be
necessary to look at the job logs for both jobs to understand the source of
the problem because no real work is being done in the job performing the SQL
statements.</p>
<p>When running in SQL server mode, only SQL interfaces can be used to perform
work under commitment control. Embedded SQL or Call Level Interface (CLI)
can be used. All connections made through embedded SQL in a single thread
are routed to the same back-end job. This allows a single commit request to
commit the work for all the connections, just as it can be in a job that is
not running in SQL server mode. Each connection made through the CLI is routed
to a separate job. The CLI requires work that is performed for each connection
to be committed or rolled back independently.</p>
<p>You cannot perform the following operations under commitment control when
running in SQL server mode:</p>
<ul><li>Record changes that are made with interfaces that are not SQL interfaces</li>
<li>Changes to DDM files</li>
<li>Changes to API commitment resources</li>
</ul>
<p>You cannot start commitment control directly in a job running in SQL server
mode.</p>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakjconcepts.htm" title="This topic provides information to help you understand how commitment control works, how it interacts with your system, and how it interacts with other systems in your network.">Commitment control concepts</a></div>
</div>
<div class="relconcepts"><strong>Related concepts</strong><br />
<div><a href="rzakjxatransaction.htm" title="DB2 Universal Database (UDB) for iSeries can participate in X/Open global transactions.">XA transaction support for commitment control</a></div>
<div><a href="../cli/rzadpsqlapd.htm">Run DB2 UDB CLI in server mode</a></div>
<div><a href="../cli/rzadpstartingservermode.htm">Start DB2 CLI in SQL Server Mode</a></div>
<div><a href="../cli/rzadprestrictions.htm">Restrictions for running DB2 UDB CLI in server mode</a></div>
</div>
<div class="relref"><strong>Related reference</strong><br />
<div><a href="../apis/qwtchgjb.htm">Change Job (QWTCHGJB) API</a></div>
</div>
</div>
</body>
</html>