Scott,
Thanks for adding another confirmation on QTEMP.
I think we're good on the understanding of sessions and each CGI request using it's own job.
That's why I wanted to be double-super-secret sure on QTEMP not being shared :-)
The work that is being done uses a temporary data area in QTEMP used during a single call only to store a selected record value.
I wrote the original application program several years back but several changes have been made over the years.
I believe the temporary data area in QTEMP was chosen to minimize impact at the time since our understanding was that QTEMP is not shared across jobs.
We've only had one customer who has reported this particular issue, but our devs have not been able to re-create the issue yet, so some logging may be in order before we do any changes.
Either way now I can recommend that they continue to look at the program in question and not chase shared QTEMP issues.
I'll report back in once we find the real culprit since this raised some interesting discussion.
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com
------------------------------
message: 3
date: Sat, 4 Mar 2017 19:35:35 -0600
from: Scott Klement <web400@xxxxxxxxxxxxxxxx>
subject: Re: [WEB400] Question on QTEMP and CGI Jobs
Richard,
I agree with what everyone else has said, Apache never uses the same job
two run two CGI requests concurrently via threads.
It does have the capability to start CGI jobs as "multiple thread
capable" (there's an Apache directive to enable this). But, this only
marks the job as capable of multiple threads so that the CGI job can
internally spawn threads if it desires. Apache does not call it in a
multiple concurrent thread manner.
Are you "absolutely" sure that the programmer isn't confusing a request
(or a "call" as you've phrased it) with a session? Because within the
scope of a session, it's very possible (and likely) that other sessions
will also be serviced by the same job with the same QTEMP. And
conversely, it is also true that a single session will be handled by
multiple jobs with different QTEMPs.
This is a very common mistake that people make. And, it can be hard to
detect during testing, because frequently the load on the test HTTP
server isn't very high, so it may come back with the same job for all
requests in the session just by "luck." But in production server where
there are more requests, it'll almost certainly switch jobs during a
session, and re-use the same job for other sessions.
In fact, if your programmer does in fact understand the difference
between requests and sessions and knows that the QTEMP is used in a
valid manner (i.e. only during the space of a single REQUEST) then I'm
having a hard time even understanding what value QTEMP provides? Since
the data can only reside there (legimately, anyway) for a very small
time, and you can't use it to keep data persistent within the session,
what purpose does it serve to use QTEMP? Something like an *OUTFILE
option that you're going to immediately process and then delete would be
one legitimate use... but that's about it.
Of course, if we're talking about persistent CGI, that's a different
story...
-SK
On 3/4/17 12:33 PM, Richard Schoen wrote:
I was chatting offline with someone else here from the list and this
has brought up the following follow on question in my head:
Are we "absolutely" sure that each individual synchronous CGI call
through the Apache server gets serviced by a separate single job
instance and not potentially by multiple threads within a single CGI
job instance ?
If the latter condition occurs within the modern Apache Server then
the argument NOT to use QTEMP is very valid because two threads in
the same job would have access to the same QTEMP instance.
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com
midrange.com
