We're essentially the same, but with a bit of a twist.
For connections that aren't doing any updates to the database,
all applications use a connection pool that authenticates to the
database as a single generic user id.
For connections that are doing updates to the database,
we have an IBM-developed J2C connection factory that
provides a connection pool of JDBC connections
authenticated using EIM Identity Tokens. The pool keeps
track of the connection and its associated WebSphere
subject, so a user reuses connections as long as they're
active on the system.
________________________________________
From: web400-bounces@xxxxxxxxxxxx [web400-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich [WaldenL@xxxxxxxxxxxxxxx]
Sent: Monday, October 27, 2008 5:29 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Persistent Sessions in DB connection for QZDASOINIT, implemented by Nathan
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
--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/web400.
midrange.com
