Re: Additional 16 megabytes of storage allocated for this job... why?

    Hi Ken,

> Are you saying that this is almost always an indication of an IBM
> problem?  Or, can this message appear in jobs for a problem with our
> coding or methods?  I was thinking our code is probably the problem, but
> why and how do we fix it.  BUT, I would love to blame IBM ;-).

    Actually, I would say problems with retaining connections is almost
always due to internal code problems.  My presumption was that you had a
test case where you knew your code was correct and were seing the PWS0083
messages.

    In general, you want to make absolutely sure that all client code looks
like this:

Connection con = null;
try
{
  // get connection and do stuff
}
catch( Exception eVarious )
{
  // error processing
}
finally
{
   if( con != null )
   {
      try
      { con.close(); }
      catch( Exception e ) {}
   }
}

    The finally block ensures that the connection is "closed".  When
connection pools are used, the close() method is overridden to return the
connection to the pool rather than actually closing the connection.  Using
that form makes the same code work transparently with or without a pool.
One way to avoid having this code repeated all over the place is to create
generic modules for the few SQL operations, generally SELECT, INSERT, UPDATE
and DELETE, so that you only pass in SQL statements and the reset is handled
for you.

    That's the first thing to check in your code, and I expect you are
already aware of that.

    Next, writing your own connection pool correctly turns out to be a
tricky thing.  Yours may well work correctly, but in general, I agree with
the jTDS people ( a JDBC driver project ) who don't provide a connection
pool with the driver.  Why? "the reason for leaving these out is that there
are free implementations available, probably much better than anything we
could come up with."  And then you don't have to debug your pool code for
things like dangling or dead connections, resetting autocommit, bookkeeping,
growth, shrinkage, and so on.

    HTH,

                                                         Joe Sam

Joe Sam Shirah -        http://www.conceptgo.com
conceptGO       -        Consulting/Development/Outsourcing
Java Filter Forum:       http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International?    http://www.jguru.com/faq/I18N
Que Java400?            http://www.jguru.com/faq/Java400


----- Original Message ----- 
From: "TitanRebel" <TitanRebel@xxxxxxxxxxx>
To: "Java Programming on and around the iSeries / AS400"
<java400-l@xxxxxxxxxxxx>
Sent: Thursday, November 10, 2005 2:11 PM
Subject: Re: Additional 16 megabytes of storage allocated for this job...
why?


> Joe,
>
> Thanks for the quick response.  The first thing I did was google... I
> should have said that in the original question.  I saw both of those,
> and both are fixes for IBM problems.  We seem to be up to date on PTFs.
>
> Are you saying that this is almost always an indication of an IBM
> problem?  Or, can this message appear in jobs for a problem with our
> coding or methods?  I was thinking our code is probably the problem, but
> why and how do we fix it.  BUT, I would love to blame IBM ;-).
>
> Ken.
>
>
> Joe Sam Shirah wrote:
>
> >     Hi Ken,
> >
> >     http://www.google.com/search?q=PWS0083
> >
> >     Most of the info you need is in the first two items.
> >
> >
> >                                                          Joe Sam
> >
> > Joe Sam Shirah -        http://www.conceptgo.com
> > conceptGO       -        Consulting/Development/Outsourcing
> > Java Filter Forum:       http://www.ibm.com/developerworks/java/
> > Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
> > Going International?    http://www.jguru.com/faq/I18N
> > Que Java400?            http://www.jguru.com/faq/Java400
> >
> >
> > ----- Original Message ----- 
> > From: "TitanRebel" <TitanRebel@xxxxxxxxxxx>
> > To: "Java Programming on and around the iSeries / AS400"
> > <java400-l@xxxxxxxxxxxx>
> > Sent: Thursday, November 10, 2005 1:22 PM
> > Subject: Additional 16 megabytes of storage allocated for this job...
why?
> >
> >
> >
> >>In many QZDASOINIT jobs, we find the PWS0083 message:
> >>
> >>Additional 16 megabytes of storage allocated for this job.
> >>
> >>Is this message "normal", or does it point to a memory leak.  We are
> >>using our own implementation of connection pooling, and some JDBC
> >>connections can potentially stay in memory and used over and over for
> >>quite a long time (days).  Is this a problem?
> >>
> >>Do we need to close and open new JDBC connections more frequently to
> >>allow these jobs to release the resources (I'm just assuming that they
> >>would release the resources after closing the JDBC Connection)?
> >>
> >>Thanks,
> >>
> >>Ken
> >>--