This is expected. Closing a connection does not guarantee that Statements
will get closed so you must explicitly do this. These should also be done
in finally blocks to assure they occur even when a SQLException is thrown.
Do note, as per the JDBC spec, calling Statement.close() will close all
ResultSet instances created by that Statement.
Dave Wolf
Internet Applications Division
Sybase
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Schultz, Bob (Consultant)
> Sent: Monday, September 25, 2000 11:46 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Cursors Open problem with multiple insertions
>
>
> I also had this problem with Oracle. A quick search on deja.com led me to
> the solution (it SEEMS to be working!) that says we must
> explicitly perform
> a close() on the statement object you are using. In fact, you are likely
> best off closing every result set and statement object, then closing the
> connection, for every database call you make.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 25, 2000 10:27 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Cursors Open problem with multiple insertions
>
>
> I made the same experience. I don't know if the DB (Oracle in my case) or
> the Appserver (Inprise in my case) is responsible for the cursors, but it
> seems that the cursors are closed on time-out basis. i've set the
> max_cursor
> setting of oracle to 500 and now it works. In my ejb scenario there are
> always about 70 cursors open and this number seems to be
> relatively constant
> (in my scenario).
>
> > -----Original Message-----
> > From: Purushotham Das K [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, September 14, 2000 7:32 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Cursors Open problem with multiple insertions
> >
> >
> > hi,
> > i am not using JDBC call to insert records in to DB. Instead
> > i am invoking
> > the create method of Entity bean multiple times with different values.
> > Surprising , this invocation is giving the 'Cursors " problem
> > when I go for
> > more than 12 insertions.
> >
> > Urgent help is required in this regard
> >
> > Thanks in advance
> > Purush
> >
> >
> >
> >
> >
> >
> > > ----- Original Message -----
> > > From: Gene Chuang <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Thursday, September 14, 2000 12:32 AM
> > > Subject: Re: Cursors Open problem with multiple insertions
> > >
> > >
> > > > Hi Dave,
> > > >
> > > > The only real difference between your code and mine is you have an
> > > > outer-most try block that catches a general Exception (possibly
> > > > NullPointerException)... your code is no more impervious to
> > > null-pointers
> > > > than mine, because:
> > > >
> > > > Connection con = null;
> > > > con = ds.getConnection();
> > > >
> > > > and
> > > > Connection con = ds.getConnection();
> > > >
> > > > is exactly the same thing! (And like you correctly
> > noted, I did the
> > > former
> > > > to avoid the annoying varible-scope problem.)
> > > >
> > > > Both ways of implementation will give one the same
> > results; it's just
> > > up
> > > to
> > > > the individual developer to determine if a SQL resource
> > errors should be
> > > > caught by an outer-most try block and handled explicitly,
> > or implicitly
> > > > ignored (close resource only if not null).
> > > >
> > > > And a minor note, you will need yet a third nested
> > try-finally block in
> > > your
> > > > code to close your ResultSet... Hence one can argue that
> > my code is
> > > > "prettier" ;-) even if it requires 3 explicit conditional
> > checkers. I
> > > think
> > > > the best (prettiest and most optimized) pattern would be
> > a combination
> > > of
> > > > both of our implementations:
> > > >
> > > > try
> > > > {
> > > > Connection con = null;
> > > > Statement stmt = null;
> > > > ResultSet result = null;
> > > > try
> > > > {
> > > > ...
> > > > }
> > > > finally
> > > > {
> > > > con.close();
> > > > stmt.close();
> > > > result.close();
> > > > }
> > > > }
> > > > catch(Exception e)
> > > > {
> > > > ... handle possible NullPointerException as well as other
> > > exceptions
> > > > }
> > > >
> > > > This pattern has only 2 try blocks (one nested in another) and no
> > > explicit
> > > > null checkers!
> > > >
> > > > Gene
> > > >
> > > > -----Original Message-----
> > > > From: A mailing list for Enterprise JavaBeans development
> > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Wolf
> > > > Sent: Wednesday, September 13, 2000 11:23 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: Cursors Open problem with multiple insertions
> > > >
> > > >
> > > > Gene,
> > > >
> > > > Let me share another design pattern or "template" for
> > working with JDBC
> > > I
> > > > much prefer.
> > > >
> > > > I have great concerns with designs like this where you "prototype"
> > > members
> > > > as null pointers just to get around the compiler's
> > scoping issue with a
> > > > finally clause. Basically the compiler is telling you
> > that your member
> > > is
> > > > out of scope in the finally that you declared in the try
> > and is hence
> > > not
> > > > definately assinged. Many people get around this by
> > setting the member
> > > to
> > > > null. My problem is you have introduced a null pointer
> > right into your
> > > > code. Now to work around the danger of your null
> > pointer, you have to
> > > add
> > > > conditional logic to prevent accidentally touching this
> > null pointer.
> > > > Dangerous and error prone in my opinion.
> > > >
> > > > I would instead use a design like the below. It still
> > uses a finally
> > > block,
> > > > has no chance of an object not being definately assigned,
> > and, has no
> > > > intrinsic null pointers.
> > > >
> > > > Connection con;
> > > > PreparedStatement pstmt;
> > > >
> > > > try
> > > > {
> > > > Context ctx = getInitialContext();
> > > > DataSource ds = (DataSource) ctx.lookup(CACHE_NAME);
> > > > con = ds.getConnection();
> > > > try
> > > > {
> > > > pstmt = con.prepareStatement("SELECT id,
> > balance FROM
> > > > account WHERE id
> > > > =?");
> > > > pstmt.setInt(1, _id);
> > > > try
> > > > {
> > > > ResultSet rs = pstmt.executeQuery();
> > > > rs.next();
> > > > _id = rs.getInt(1);
> > > > _balance = rs.getFloat(2);
> > > > }
> > > > finally
> > > > {
> > > > pstmt.close();
> > > > }
> > > > }
> > > > finally
> > > > {
> > > > con.close();
> > > > }
> > > > }
> > > > catch(Exception e)
> > > > {
> > > > e.printStackTrace();
> > > > throw new java.rmi.RemoteException();
> > > > }
> > > >
> > > > The finallys although not all at the end, do indeed fire
> > last (as per
> > > > Goslings spec), and I now dont need null pointers.
> > > >
> > > > Whatcha think?
> > > >
> > > > Dave Wolf
> > > > Internet Applications Division
> > > > Sybase
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: A mailing list for Enterprise JavaBeans development
> > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Gene Chuang
> > > > > Sent: Wednesday, September 13, 2000 1:50 PM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Re: Cursors Open problem with multiple insertions
> > > > >
> > > > >
> > > > > Good call Ana; and the following "template" is how you should
> > > > > implement all
> > > > > your jdbc calls:
> > > > >
> > > > >
> > > > > Connection conn = null;
> > > > > PreparedStatement stmt = null;
> > > > > ResultSet results = null;
> > > > > try
> > > > > {
> > > > > conn = dataSource.getConnection();
> > > > > stmt = conn.getPreparedStatement();
> > > > > results = stmt.execute();
> > > > > }
> > > > > catch(SQLException se)
> > > > > {
> > > > > }
> > > > > finally
> > > > > {
> > > > > if(results !=null) results.close();
> > > > > if(stmt !=null) stmt.close();
> > > > > if(conn !=null) conn.close();
> > > > > }
> > > > >
> > > > > Gene Chuang
> > > > > Teach the world... Join Kiko!
> > > > > <http://www.kiko.com/profile/join.jsp?refcode=TAF-gchuang>
> > > > >
> > > > > -----Original Message-----
> > > > > From: A mailing list for Enterprise JavaBeans development
> > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > Bhattacharyya, Ana
> > > > > Sent: Wednesday, September 13, 2000 9:20 AM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Re: Cursors Open problem with multiple insertions
> > > > >
> > > > >
> > > > > well this can happen if u are not closing ur ResultSet or
> > > > > statement objects.
> > > > > Do close them in the finally block of ur code.
> > > > > HTH
> > > > > Ana
> > > > >
> > > > > -----Original Message-----
> > > > > From: Purushotham Das K [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Wednesday, September 13, 2000 12:08 PM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Cursors Open problem with multiple insertions
> > > > >
> > > > >
> > > > > Hi Folks
> > > > >
> > > > > I am getting the folllowing error ----> " Maximum Number
> > > > > of Cursors
> > > > > Opened"
> > > > > I have written a session bean that is accessing
> > an entity
> > > > > bean. Iam
> > > > > working on weblogic 5.1 on solaris server.
> > > > > When I insert 13 or more rows into a table in a
> > single call to
> > > > > session bean, I get the above error. Everything's fine
> > when I try
> > > > > to insert
> > > > > less number of records
> > > > > Can somebody enlighten me on this error?
> > > > >
> > > > > Thanks in advance
> > > > > Purush
> > > > >
> > > > >
> > ==================================================================
> > > > > =========
> > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include
> > > > > in the body
> > > > > of the message "signoff EJB-INTEREST". For general
> > help, send email
> > > to
> > > > > [EMAIL PROTECTED] and include in the body of the
> > message "help".
> > > > >
> > > > >
> > > > > STATEMENT OF CONFIDENTIALITY. The information
> > contained in this
> > > > > electronic
> > > > > message and any attachments to this message are intended for the
> > > exclusive
> > > > > use of the addressee(s) and may contain confidential or
> > privileged
> > > > > information. If you are not the intended recipient,
> > please notify
> > > > > USPowerSolutions Corporation immediately at (617)
> > 547-3800, or at
> > > > > [EMAIL PROTECTED], and destroy all copies of
> > this message and
> > > any
> > > > > attachments.
> > > > >
> > > > >
> > ==================================================================
> > > > > =========
> > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include
> > > > > in the body
> > > > > of the message "signoff EJB-INTEREST". For general
> > help, send email
> > > to
> > > > > [EMAIL PROTECTED] and include in the body of the
> > message "help".
> > > > >
> > > > >
> > ==================================================================
> > > > > =========
> > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include
> > > > > in the body
> > > > > of the message "signoff EJB-INTEREST". For general
> > help, send email
> > > to
> > > > > [EMAIL PROTECTED] and include in the body of the
> > message "help".
> > > > >
> > > > >
> > > >
> > > >
> > >
> > ==============================================================
> > ============
> > > =
> > > > To unsubscribe, send email to [EMAIL PROTECTED] and
> > include in the
> > > body
> > > > of the message "signoff EJB-INTEREST". For general help,
> > send email to
> > > > [EMAIL PROTECTED] and include in the body of the
> > message "help".
> > > >
> > > >
> > >
> > ==============================================================
> > ============
> > > =
> > > > To unsubscribe, send email to [EMAIL PROTECTED] and
> > include in the
> > > body
> > > > of the message "signoff EJB-INTEREST". For general help,
> > send email to
> > > > [EMAIL PROTECTED] and include in the body of the
> > message "help".
> >
> > ==============================================================
> > =============
> > To unsubscribe, send email to [EMAIL PROTECTED] and
> > include in the body
> > of the message "signoff EJB-INTEREST". For general help,
> > send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
