Re: JDBC connections and library lists

[Charles Wilt <charles.wilt@xxxxxxxxx>]

Chris,

That shouldn't be possible...

I could see two different apps on a single server.  But not different apps
on different servers.

Unless perhaps the apps are running on a app server cluster?

Charles



On Wed, Apr 2, 2014 at 1:14 PM, Chris Bipes <chris.bipes@xxxxxxxxxxxxxxx>wrote:

> The problem occurs when a different application running on a different
> server picks up one the QZDASOINIT jobs that was started from the
> application pool on server A.  Now I have to ask why the application pool
> is not holding a lock on the QZDASOINIT job so others will not use them?
>  (Still waiting for a response from the developer.)
>
> Chris Bipes
> Director of Information Services
> CrossCheck, Inc.
>
> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
> midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
> Sent: Wednesday, April 02, 2014 10:08 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: JDBC connections and library lists
>
> And by reused, I mean the connection is ended by the "app" and the i reuses
> the job for a new incoming connection.
>
> The problem occurs when connection pooling on the app or app server comes
> into play.  When the connection pool reuses an existing connection, from
> the IBM i perspective the connection has not been "reused" as it's been
> continually open.
>
> I suspect the issue with library lists manifests when multiple applications
> are using the same connection pool to an individual host.  Bad idea,
> instead an application specific connection pool should be used.  Besides
> the library list, you'd then be able to have application specific users for
> the connections.
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.