Re: Call Level Interface error

[Madhavan <seawolf00@xxxxxxxxx>]

Thanks everybody !! 

I will review the code and check for statements
closure as was pointed out. 

Regards
Madhavan

--- cujo@us.ibm.com wrote:
> 
> I don't think you are closing everything you think
> you are closing.  There
> is a big difference between seeing ODPs (which is
> what I thought the
> original issue was) and running out of statement
> handles in the CLI.
> Seeing ODPs is expected and is a caching feature of
> the system.  Seeing the
> handle count grow is a resource leak.
> 
> What is happening to you is that you are getting a
> connection from a pool,
> you are creating a statement (or several) with that
> connection.  You are
> doing some work  (which includes creating
> ResultSets).  You probably do
> close the ResultSets as you say, but you may not be
> closing all the
> statements that you created.  If you do not close
> statements under a
> connection and continue to get new ones, your
> application will crash.
> There is no way for the JDBC driver to stop it
> (before JDK 1.2).
> 
> The garbage collector can't save you from this type
> of leak.  This is
> because even though your application has given up
> its reference to the
> Statement object, the JDBC driver itself has not. 
> Therefore when the
> garbage collector runs, the 'lost' statement handles
> are still reachable.
> 
> With JDK 1.2, the native JDBC driver can actually
> recover from most leak
> situations.  The way this is done is by replacing
> the references in the
> JDBC driver with 'WeakReferences'.  These are a new
> type of reference in
> JDK 1.2 and it basically tell the garbage collector
> that, assuming this is
> the only reference left to the object (meaning the
> user app 'lost' their
> reference), go ahead and garbage collect this
> object.  When the object gets
> garbage collected, the finalizer for the object runs
> and the database
> resources get freed.
> 
> The other possibility is that you are trying to
> create too many statements
> under a connection (if you need 1000 statements at a
> time, its the same as
> leaking until you have 1000 statements out there,
> right?).  I assume this
> isn't the case, but it is fair to mention it. :)
> 
> Regards,
> 
> Richard D. Dettinger
> AS/400 Java Data Access Team
> 
> "TRUE! nervous, very, very dreadfully nervous I had
> been and am; but why
> WILL you say that I am mad?
> The disease had sharpened my senses, not destroyed,
> not dulled them. "
> 
> - Edgar Allan Poe
> "The Tell-Tale Heart"
> 
> 
> 
> 
> Madhavan <seawolf00@yahoo.com>@midrange.com on
> 09/29/2000 06:45:37 PM
> 
> Please respond to JAVA400-L@midrange.com
> 
> Sent by:  owner-java400-l@midrange.com
> 
> 
> To:   JAVA400-L@midrange.com
> cc:
> Subject:  Re: Call Level Interface error
> 
> 
> 
> Guys,
> 
> This is the Call Level Interface error that I get in
> the middle of processing after which the job runs
> allright. Typically I have seen that File ODPs are
> open and exceeds 512 for a type II driver which
> cause
> the job to abort.
> 
> I am attaching the job log which givers SQL error
> type
> 14  - Maximum number of handles allocated.
> 
> This pertains to my earlier questions about why
> despite releasing connections, closing result set
> etc.. the file ODPs in QSQLSRVR is still open
> 
> Thanks and please answer asap
> 
> Regards
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Photos - 35mm Quality Prints, Now Get 15
> Free!
> http://photos.yahoo.com/
>  SQ99999    Diagnostic              30    09/29/00  
> 16:06:49   QSQCLI
> QSYS        *STMT    QSQCLI       QSYS
>                                       From module .
> . . . . . . . :   SQLAH
>                                       From procedure
>  . . . . . . :
> SQLAllocHandle
>                                       Statement . .
> . . . . . . . :   4288
>                                       To module . .
> . . . . . . . :   SQLAS
>                                       To procedure 
> . . . . . . . :
> SQLAllocStmt
>                                       Statement . .
> . . . . . . . :   3817
>                                       Thread  . . .
> . :   0000003F
>                                       Message . . .
> . :   Error Occurred in
> SQL Call Level Interface
>                                       Cause . . . .
> . :   You have issued a
> procedure call that encountered an
>                                         error.  The
> error code is 14. Error
> codes are as follows: -- Error type 3 is
>                                         program type
> out of range. -- Error
> type 4 is SQL data type out of range. --
>                                         Error type 9
> is argument value not
> valid. -- Error type 10 is function
>                                         sequence
> error. -- Error type 12 is
> transaction operation state not valid.
>                                         -- Error
> type 13 is memory
> management problem. -- Error type 14 is maximum
>                                         number of
> handles allocated. --
> Error type 15 is no cursor name available.
>                                         -- Error
> type 16 is handle type for
> operation not valid. Recovery  . . . :
>                                         Refer to the
> DB2 for AS/400 SQL
> Call Level Interface (ODBC) book for a
>                                        complete
> description of the error.
> Specifically, look under the procedure
>                                        that sent the
> error.
> MCH3601    Escape                  40    09/29/00  
> 16:06:56   QJVAJDBC
> QJAVA       *STMT    QJVAJDBC     QJAVA        *STMT
>                                      From module . .
> . . . . . . :
> QJVASTAT
>                                      From procedure 
> . . . . . . :
> Java_com_ibm_db2_jdbc_app_DB2StatementRuntimeI
>                                       
> mpl_SQLFreeStmt
>                                      Statement . . .
> . . . . . . :   910
>                                      To module . . .
> . . . . . . :
> QJVASTAT
>                                      To procedure  .
> . . . . . . :
> Java_com_ibm_db2_jdbc_app_DB2StatementRuntimeI
>                                       
> mpl_SQLFreeStmt
>                                      Statement . . .
> . . . . . . :   910
>                                      Thread  . . . .
> :   00000013
>                                      Message . . . .
> :   Pointer not set
> for location referenced.
>                                      Cause . . . . .
> :   A pointer was
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
http://photos.yahoo.com/
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---