Re: Life cycle of QZDASOINIT

Thaks Elvis.  I've read your article using the link Charles sent me.  It
was very helpful.  This J2EE uses Spring frame work and Hibernate to do
JDBC request.  Still trying to figure how this frame work handle closing
and opening of connection pool.  Sigh....  voodoo migic.



"Elvis Budimlic" <ebudimlic@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:<mailman.17435.1247500110.23468.midrange-l@xxxxxxxxxxxx>...

You're on the correct track with your thinking of examining the client

code

further.
What sometimes happens in J2EE environment is that the application

server

creates a database connection pool of its own, thus never ending the

PJs on

the database server (iSeries) and instead managing the number of live
connections itself. App server does this for performance reasons (i.e.

PJs

never have to be recycled by the OS, instead they are kept connected

and

service many different client connections).

The only time OS will create a new QZDASOINIT job instead of reusing

an

existing Prestart Job is when the maximum threshold is reached.  Then

it

will create an X amount of new PJs for the future use of incoming

(client)

connection requests. You can see this value by doing the following:

DSPSBSD QUSRWRK
10
5 against QZDASOINIT entry

Hth, Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com


-----Original Message-----
Subject: Re: Life cycle of QZDASOINIT

Thank you for the info.  I'm currently having some problems with one

of my

J2EE application regarding QZDASOINIT job.  When I start this

application,

everything looks fine.  However, about 30 mins later, I'll see

thousand of

QZDASOINIT jobs start to fire off in QUSRWRK subsystem.  This lead me

to

think that this application is not closing the connection after using

it.

Going back to digging.

--
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.