× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thank you for all the input. I think I've found the problem. It seems like
a Websphere Apps server related problem. Here is what happened: Our
application uses AS400JDBCConnectionPoolDataSource class as the way to get
connectionPool and connection from iseries. This application does not have
code to set maxActive (maxConnection) attribute of the ConnectionPool
object. This appears to be OK when running the applications in a stand
alone or jBOSS environment. But in Websphere env, the connections seems to
keep going up. Below is a link that may have reference the problem that I'm
experencing:

http://www.coderanch.com/t/450695/Websphere/Connection-pool-issue




"Charles Wilt" <charles.wilt@xxxxxxxxx> wrote in message
news:mailman.17579.1247579689.23468.midrange-l@xxxxxxxxxxxxxxx
Lim,

I think by default Spring/Hibernate leaves the connections open.
However, I believe you can change a setting so that it will only keep
X number of available connections open and close any extra.

Charles

On Tue, Jul 14, 2009 at 9:24 AM, Lim
Hock-Chai<Lim.Hock-Chai@xxxxxxxxxxxxxxx> wrote:
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.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.