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

Reply via email to