问题描述
关于
在Windows 2000 / XP / 2003上同时访问DB2(8.1.5)的允许性,文档不清楚(至少对我来说),
具有单独的事务范围,来自使用嵌入式SQL的多线程
程序的单独线程。由于线程不需要共享
事务范围,因此sqleAttachToCtx系列API似乎不需要
。
< quote>
在针对DB2
数据库的线程应用程序的默认实现中,对数据库的访问序列化由
$ b $强制执行b数据库API。如果一个线程执行数据库调用,其他
线程的调用将被阻塞,直到第一个调用完成,即使
后续调用访问与之无关的数据库对象第一个
电话。此外,进程中的所有线程共享提交范围。真正的
只能通过单独的
流程或使用本节中描述的API来实现对数据库的并发访问。
< / quote>
表示不,我需要单独的流程。
但是2段之后:
< quote>
对于DB2 Version 8,默认情况下所有版本8应用程序都是多线程的,
并且能够使用多个上下文。 (版本8之前的行为
应用程序保持不变。)如果需要,可以使用以下DB2
API来使用多个上下文。具体来说,您的应用程序可以为线程创建一个
上下文,附加到每个
线程的单独上下文或从中分离,并在线程之间传递上下文。如果您的应用程序没有调用任何这些API,那么DB2将自动管理您的应用程序的多个上下文:
< / quote> ;
看起来情况正好相反 - 事实上,默认情况下它表示它会完全符合我的要求。
对于CLI,文档确认了多线程支持:
< quote>
DB2 CLI自动使用多个上下文来实现线程安全,
支持多线程的平台上的
并发数据库访问。
< / quote>
但不表示这是否适用于嵌入式SQL。 />
相比之下,对于嵌入式SQL下的COBOL,FORTRAN和REXX,以及Perl,
,文档明确指出:COBOL / FORTRAN / REXX / Perl不支持
支持多线程数据库访问,但没有进一步的解释是给出了
。对于C / C ++,没有声明。我知道嵌入式SQL
API(如预编译器可下载文档中所述)存在于
C和泛型样式中 - 是语言预编译器选择的API
或许相关因素? (我们正在使用IBM PL / I for Windows 2.1.12,其中
具有原生多线程,我还没有检查过使用哪种API所以
远)。
有人知道现实是什么吗?
The documentation is unclear (at least to me) on the permissibility of
accessing DB2 (8.1.5) concurrently on and from Windows 2000 / XP / 2003,
with separate transactions scope, from separate threads of a multithreaded
program using embedded SQL. Since the threads do not need to share
transaction scopes, the sqleAttachToCtx family of APIs do not seem to be
necessary.
<quote>
In the default implementation of threaded applications against a DB2
database, serialization of access to the database is enforced by the
database APIs. If one thread performs a database call, calls made by other
threads will be blocked until the first call completes, even if the
subsequent calls access database objects that are unrelated to the first
call. In addition, all threads within a process share a commit scope. True
concurrent access to a database can only be achieved through separate
processes, or by using the APIs that are described in this section.
</quote>
indicates no, I need separate processes.
But 2 paragraphs later:
<quote>
For DB2 Version 8, all Version 8 applications are multithreaded by default,
and are capable of using multiple contexts. (The behavior of pre-Version 8
applications remains unchanged.) If you want, you can use the following DB2
APIs to use multiple contexts. Specifically, your application can create a
context for a thread, attach to or detach from a separate context for each
thread, and pass contexts between threads. If your application does not call
any of these APIs, DB2 will automatically manage the multiple contexts for
your application:
</quote>
exactly the opposite appears to be the case - in fact, it says it will do
exactly what I want, by default.
For CLI, the documentation confirms the multithreaded support:
<quote>
The DB2 CLI automatically uses multiple contexts to achieve thread-safe,
concurrent database access on platforms that support multi-threading.
</quote>
but does not indicate whether this applied to embedded SQL.
By contrast, for COBOL, FORTRAN and REXX under "Embedded SQL", and for Perl,
the the documentation clearly states: "COBOL/FORTRAN/REXX/Perl does not
support multiple-thread database access", but no further explanation is
given. For C/C++ the statement is not made. I know that the embedded SQL
APIs (as documented in the precompiler downloadable documentation) exist in
both C and generic styles - is the choice of API by the language precompiler
perhaps the relevant factor? (We''re using IBM PL/I for Windows 2.1.12, which
has native multithreading, I haven''t examined which API is being used so
far).
Does anybody know what the reality is?
推荐答案
您好,
我无法回答这个问题。
但是我可以在一个我可能有帮助的问题上添加一些评论
来解决这两个问题。
我的目标是:我如何混合嵌入式sql和cli,并为cli连接和嵌入式sql连接保持单独的
事务,
这个过程只有一个线程但可以有一个嵌入式sql
" session / connect"和一个或多个cli会话/连接。
DB2 LUW手册说:
"混合嵌入式SQL和DB2 CLI
在应用程序中使用DB2 CLI与嵌入式静态SQL结合使用DB2 CLI是可能的,有时也是可取的。考虑场景
,其中应用程序开发人员希望利用DB2 CLI目录函数提供的易用性和最大化
应用程序处理性能至关重要的部分。
为了混合使用DB2 CLI和嵌入式SQL,应用程序
必须符合以下规则:
必须完全使用DB2 CLI或嵌入式SQL执行所有连接管理和事务管理
- 绝不会混合使用
两个。应用程序有两个选项:
它使用DB2 CLI调用执行所有连接和提交/回滚,
然后调用使用嵌入式SQL编写的函数;
或它使用嵌入式SQL执行所有连接和提交/回滚,然后调用使用DB2 CLI API的函数,特别是null
连接。 br />
查询语句处理不能跨越DB2 CLI和嵌入式SQL
接口的相同语句。例如,应用程序无法使用嵌入式SQL打开游标,然后调用DB2 CLI SQLFetch()
函数来检索行数据。
由于DB2 CLI允许多个连接,因此必须在执行任何嵌入式SQL之前调用SQLSetConnection()
函数。这个
允许应用程序明确指定执行嵌入式SQL处理的$ / b $ b下的连接。
如果是DB2 CLI应用程序是多线程的,并且还嵌入了
SQL调用或DB2 API调用,然后每个线程必须具有DB2上下文。
"
我不明白这个。
我明白嵌入的sql游标不能被cli
或其他方式处理周围。但是为什么连接管理和
事务管理必须在嵌入式sql中或者在CLI中?
(独家)?
我的我认为嵌入式sql en cli有(应该有?)他们自己的
上下文。如果要完成cli sql,该过程将首先保存
上下文(无论它是什么),设置它自己的上下文,做它的工作(可以
是一个提交)然后将上下文恢复到在此特定cli上下文中工作的
之前找到的内容(Unix方式:当需要一个
特殊状态时,保存状态,执行动作,恢复状态
完成)。这将允许嵌入式sql和cli完全拆分(我需要的是什么
)。
我的调查是在7.2。我从在线手册中复制的是
(另外)8.2解释。
那么db2(luw)中的上下文究竟是什么用于,并基于它,
如何解释有关连接管理的约束和
事务管理当嵌入式sql en cli用于一个
程序/流程?它基于非多线程流程
环境,但也许它可以帮助回答原始帖子
。
Bernard Dhooghe
Hello,
I can not answer the question.
But I can add some comments on a question I have that maybe could help
to shade a light on both problems.
My goal was/is: how can I mix embedded sql and cli and keep separate
transactions for the cli connections and the embedded sql connection,
the process having just one thread but can have one embedded sql
"session/connect" and one or more cli "sessions/connects".
The DB2 LUW manual says:
"Considerations for mixing embedded SQL and DB2 CLI
It is possible, and sometimes desirable, to use DB2 CLI in conjunction
with embedded static SQL in an application. Consider the scenario
where the application developer wishes to take advantage of the ease
of use provided by the DB2 CLI catalog functions and maximize the
portion of the application''s processing where performance is critical.
In order to mix the use of DB2 CLI and embedded SQL, the application
must comply with the following rules:
All connection management and transaction management must be performed
completely using either DB2 CLI or embedded SQL - never a mixture of
the two. Two options are available to the application:
it performs all connects and commits/rollbacks using DB2 CLI calls,
and then calls functions written using embedded SQL;
or it performs all connects and commits/rollbacks using embedded SQL,
and then calls functions that use DB2 CLI APIs, notably, a null
connection.
Query statement processing cannot straddle DB2 CLI and embedded SQL
interfaces for the same statement. For example, the application cannot
open a cursor using embedded SQL, and then call the DB2 CLI SQLFetch()
function to retrieve row data.
Since DB2 CLI permits multiple connections, the SQLSetConnection()
function must be called prior to executing any embedded SQL. This
allows the application to explicitly specify the connection under
which the embedded SQL processing is performed.
If the DB2 CLI application is multithreaded and also makes embedded
SQL calls or DB2 API calls, then each thread must have a DB2 context.
"
I do not understand this.
I understand that the embedded sql cursor can not be processed by cli
or the other way around. But why must connection management and
transaction management either be in embedded sql or either in CLI
(exclusively)?
My thinking was that embedded sql en cli have (should have?) their own
context. If cli sql is to be done, the process will first save the
context (whatever it may be), set it''s own context, do its work (could
be a commit) and then restore the context to what was found before
working in this particular cli context (the Unix way: when needing a
special state, save the state, do the action, restore the state when
done). That would allow embedded sql and cli to be totally split (what
I needed).
My investigation was in 7.2. What I copied from the on-line manual is
(also) the 8.2 explanation.
So what exactly is a context in db2 (luw) used for, and based on it,
how to explain the constraint concerning connection management and
transaction management when both embedded sql en cli are used in one
program/process? It is based on a non multi-threaded process
environment, but maybe it could help to answer the original posting
also.
Bernard Dhooghe
news:< ci ********** @ ngspool-d02.news.aol.com> ...
news:<ci**********@ngspool-d02.news.aol.com>...
您好,
我无法回答这个问题。
但我可以在我提出的问题上添加一些评论可能有助于对两个问题进行分析。
我的目标是:我如何混合使用嵌入式sql和cli并保持单独只有一个线程但可以有一个嵌入式sql的进程
session / connect DB2 LUW手册说:
混合使用嵌入式SQL和DB2 CLI的注意事项
它是一个或多个cli会话/连接。
将DB2 CLI与应用程序中的嵌入式静态SQL结合使用是可能的,有时是可取的。考虑这样的场景:应用程序开发人员希望利用DB2 CLI目录函数提供的易用性,并最大限度地提高应用程序处理性能至关重要的部分。
为了混合使用DB2 CLI和嵌入式SQL,应用程序必须遵守以下规则:
必须执行所有连接管理和事务管理完全使用DB2 CLI或嵌入式SQL - 绝不是两者的混合。应用程序有两个选项:
它使用DB2 CLI调用执行所有连接和提交/回滚,然后调用使用嵌入式SQL编写的函数;
或执行所有连接和提交/回滚使用嵌入式SQL,然后调用使用DB2 CLI API的函数,特别是null
连接。
查询语句处理不能跨越DB2 CLI和嵌入式SQL接口同样的声明。例如,应用程序无法使用嵌入式SQL打开游标,然后调用DB2 CLI SQLFetch()函数来检索行数据。
由于DB2 CLI允许多个连接,因此SQLSetConnection( )
函数必须在执行任何嵌入式SQL之前调用。这允许应用程序明确指定执行嵌入式SQL处理的
连接。
如果DB2 CLI应用程序是多线程的并且还嵌入了SQL语句调用或DB2 API调用,然后每个线程必须有一个DB2上下文。
我不明白这一点。
我明白cli
或其他方式无法处理嵌入式sql游标。但是为什么连接管理和事务管理必须在嵌入式sql中或者在CLI中(仅限于)?
我的想法是嵌入式sql en cli(应该有?) )他们自己的背景。如果要完成cli sql,进程将首先保存
上下文(无论它是什么),设置它自己的上下文,做它的工作(可能是一个提交)然后恢复在这个特定的cli环境中工作之前发现的内容(Unix方式:需要特殊状态时,保存状态,执行操作,完成后恢复状态) 。这将允许嵌入式sql和cli完全分裂(我需要的是什么)。
我的调查是在7.2。我从在线手册中复制的是
(另外)8.2解释。
那么db2(luw)中的上下文究竟是用于什么,并基于它,
当嵌入式sql en cli用于一个程序/进程时,如何解释有关连接管理和事务管理的约束?它基于一个非多线程的过程环境,但也许它可以帮助回答原来的帖子
Bernard Dhooghe
Hello,
I can not answer the question.
But I can add some comments on a question I have that maybe could help
to shade a light on both problems.
My goal was/is: how can I mix embedded sql and cli and keep separate
transactions for the cli connections and the embedded sql connection,
the process having just one thread but can have one embedded sql
"session/connect" and one or more cli "sessions/connects".
The DB2 LUW manual says:
"Considerations for mixing embedded SQL and DB2 CLI
It is possible, and sometimes desirable, to use DB2 CLI in conjunction
with embedded static SQL in an application. Consider the scenario
where the application developer wishes to take advantage of the ease
of use provided by the DB2 CLI catalog functions and maximize the
portion of the application''s processing where performance is critical.
In order to mix the use of DB2 CLI and embedded SQL, the application
must comply with the following rules:
All connection management and transaction management must be performed
completely using either DB2 CLI or embedded SQL - never a mixture of
the two. Two options are available to the application:
it performs all connects and commits/rollbacks using DB2 CLI calls,
and then calls functions written using embedded SQL;
or it performs all connects and commits/rollbacks using embedded SQL,
and then calls functions that use DB2 CLI APIs, notably, a null
connection.
Query statement processing cannot straddle DB2 CLI and embedded SQL
interfaces for the same statement. For example, the application cannot
open a cursor using embedded SQL, and then call the DB2 CLI SQLFetch()
function to retrieve row data.
Since DB2 CLI permits multiple connections, the SQLSetConnection()
function must be called prior to executing any embedded SQL. This
allows the application to explicitly specify the connection under
which the embedded SQL processing is performed.
If the DB2 CLI application is multithreaded and also makes embedded
SQL calls or DB2 API calls, then each thread must have a DB2 context.
"
I do not understand this.
I understand that the embedded sql cursor can not be processed by cli
or the other way around. But why must connection management and
transaction management either be in embedded sql or either in CLI
(exclusively)?
My thinking was that embedded sql en cli have (should have?) their own
context. If cli sql is to be done, the process will first save the
context (whatever it may be), set it''s own context, do its work (could
be a commit) and then restore the context to what was found before
working in this particular cli context (the Unix way: when needing a
special state, save the state, do the action, restore the state when
done). That would allow embedded sql and cli to be totally split (what
I needed).
My investigation was in 7.2. What I copied from the on-line manual is
(also) the 8.2 explanation.
So what exactly is a context in db2 (luw) used for, and based on it,
how to explain the constraint concerning connection management and
transaction management when both embedded sql en cli are used in one
program/process? It is based on a non multi-threaded process
environment, but maybe it could help to answer the original posting
also.
Bernard Dhooghe
default,
default,
这就是让我认为我想要的东西可以工作的原因。
多线程混合CLI /嵌入式SQL的各个方面可能与我的问题密切相关,但你没有使用它。我的问题更多的是关于预处理器生成的嵌入式SQL API调用中的线程安全性和同步,以及基于每个线程的上下文和事务性管理。
Bernard Dhooghe <无*** @ attglobal.net>在消息中写道
新闻:25 ************************** @ posting.google.c om ...
and this is what leads me to think that what I want may work.
The multithreading aspects of mixing CLI / embedded SQL are probably closely
related to my question, but you''re not using that. My question is more on of
thread safety and synchronization within the embedded SQL API calls
generated by the preprocessor, as well as of contextual and transactional
management on a per thread basis.
"Bernard Dhooghe" <no***@attglobal.net> wrote in message
news:25**************************@posting.google.c om...
新闻:< ci ********** @ ngspool-d02.news.aol.com> ...
news:<ci**********@ngspool-d02.news.aol.com>...
你好,
我无法回答这个问题。
但我可以补充一些意见我有一个问题,或许可以帮助我们解决这两个问题。
我的目标是:我如何混合嵌入式sql和cli并保持单独的交易对于cli连接和嵌入式sql连接,这个进程只有一个线程但可以有一个嵌入式sql
session / connect DB2 LUW手册说:
混合使用嵌入式SQL和DB2 CLI的注意事项
它是一个或多个cli会话/连接。
将DB2 CLI与应用程序中的嵌入式静态SQL结合使用是可能的,有时是可取的。考虑这样的场景:应用程序开发人员希望利用DB2 CLI目录函数提供的易用性,并最大限度地提高应用程序处理性能至关重要的部分。
为了混合使用DB2 CLI和嵌入式SQL,应用程序必须遵守以下规则:
必须执行所有连接管理和事务管理完全使用DB2 CLI或嵌入式SQL - 绝不是两者的混合。应用程序有两个选项:
它使用DB2 CLI调用执行所有连接和提交/回滚,然后调用使用嵌入式SQL编写的函数;
或执行所有连接和提交/回滚使用嵌入式SQL,然后调用使用DB2 CLI API的函数,特别是null
连接。
查询语句处理不能跨越DB2 CLI和嵌入式SQL接口同样的声明。例如,应用程序无法使用嵌入式SQL打开游标,然后调用DB2 CLI SQLFetch()函数来检索行数据。
由于DB2 CLI允许多个连接,因此SQLSetConnection( )
函数必须在执行任何嵌入式SQL之前调用。这允许应用程序明确指定执行嵌入式SQL处理的
连接。
如果DB2 CLI应用程序是多线程的并且还嵌入了SQL语句调用或DB2 API调用,然后每个线程必须有一个DB2上下文。
我不明白这一点。
我明白cli
或其他方式无法处理嵌入式sql游标。但是为什么连接管理和事务管理必须在嵌入式sql中或者在CLI中(仅限于)?
我的想法是嵌入式sql en cli(应该有?) )他们自己的背景。 If cli sql is to be done, the process will first save the
context (whatever it may be), set it’’s own context, do its work (could
be a commit) and then restore the context to what was found before
working in this particular cli context (the Unix way: when needing a
special state, save the state, do the action, restore the state when
done). That would allow embedded sql and cli to be totally split (what
I needed).
My investigation was in 7.2. What I copied from the on-line manual is
(also) the 8.2 explanation.
So what exactly is a context in db2 (luw) used for, and based on it,
how to explain the constraint concerning connection management and
transaction management when both embedded sql en cli are used in one
program/process? It is based on a non multi-threaded process
environment, but maybe it could help to answer the original posting
also.
Bernard Dhooghe
Hello,
I can not answer the question.
But I can add some comments on a question I have that maybe could help
to shade a light on both problems.
My goal was/is: how can I mix embedded sql and cli and keep separate
transactions for the cli connections and the embedded sql connection,
the process having just one thread but can have one embedded sql
"session/connect" and one or more cli "sessions/connects".
The DB2 LUW manual says:
"Considerations for mixing embedded SQL and DB2 CLI
It is possible, and sometimes desirable, to use DB2 CLI in conjunction
with embedded static SQL in an application. Consider the scenario
where the application developer wishes to take advantage of the ease
of use provided by the DB2 CLI catalog functions and maximize the
portion of the application''s processing where performance is critical.
In order to mix the use of DB2 CLI and embedded SQL, the application
must comply with the following rules:
All connection management and transaction management must be performed
completely using either DB2 CLI or embedded SQL - never a mixture of
the two. Two options are available to the application:
it performs all connects and commits/rollbacks using DB2 CLI calls,
and then calls functions written using embedded SQL;
or it performs all connects and commits/rollbacks using embedded SQL,
and then calls functions that use DB2 CLI APIs, notably, a null
connection.
Query statement processing cannot straddle DB2 CLI and embedded SQL
interfaces for the same statement. For example, the application cannot
open a cursor using embedded SQL, and then call the DB2 CLI SQLFetch()
function to retrieve row data.
Since DB2 CLI permits multiple connections, the SQLSetConnection()
function must be called prior to executing any embedded SQL. This
allows the application to explicitly specify the connection under
which the embedded SQL processing is performed.
If the DB2 CLI application is multithreaded and also makes embedded
SQL calls or DB2 API calls, then each thread must have a DB2 context.
"
I do not understand this.
I understand that the embedded sql cursor can not be processed by cli
or the other way around. But why must connection management and
transaction management either be in embedded sql or either in CLI
(exclusively)?
My thinking was that embedded sql en cli have (should have?) their own
context. If cli sql is to be done, the process will first save the
context (whatever it may be), set it''s own context, do its work (could
be a commit) and then restore the context to what was found before
working in this particular cli context (the Unix way: when needing a
special state, save the state, do the action, restore the state when
done). That would allow embedded sql and cli to be totally split (what
I needed).
My investigation was in 7.2. What I copied from the on-line manual is
(also) the 8.2 explanation.
So what exactly is a context in db2 (luw) used for, and based on it,
how to explain the constraint concerning connection management and
transaction management when both embedded sql en cli are used in one
program/process? It is based on a non multi-threaded process
environment, but maybe it could help to answer the original posting
also.
Bernard Dhooghe
这篇关于关于8.1.5的嵌入式SQL和多线程问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!