Re: Persistent Sessions in DB connection for QZDASOINIT, implemented by Nathan

Not that we are talking directly about this, but I wanted to note a danger
in sharing jobs.

The single job for many users carries the same worries that RPG+CGI does if
you are doing SQL stored procedures calling RPG programs (i.e. global
variables are shared across requests regardless of if it is a different
user). Basically it means you need to inz your variables responsibly on the
RPG side for each request and don't assume it is the same user.

I have been bit in the butt by that one :-)

Aaron Bartell
http://mowyourlawn.com

On Mon, Oct 27, 2008 at 4:29 PM, Walden H. Leverich <WaldenL@xxxxxxxxxxxxxxx

wrote:

So out of curiosity, what criteria do folks use to draw the line?

In my case I don't draw the line, each request is a "new" connection.
Now the connections are in a connection pool, so to the 400 this seems
to be just another request in the same job, but there is no retained
state between the requests. Each request stands on its own, and _could_
be sent on a brand spankin' new connection, it's just a performance
tweak that we reuse the connection.

As for the different frames, since it's a different connection for each,
no harm.

-Walden