It seems it is an Oracle configuration problem. Check the vallus of
OPEN_CURSORS and MAXOPENCURSORS parameter values in INIT.ORA
And the following lines from Oracle document may help you to understand the
problem more.
-- Venkat.
MAXOPENCURSORS
Purpose : Specifies the number of concurrently open cursors that the
precompiler tries to keep cached.
Syntax : MAXOPENCURSORS=integer
Default : 10
Usage Notes
You can use MAXOPENCURSORS to improve the performance of your program. For
more information, see Appendix C.
When precompiling separately, use MAXOPENCURSORS as described in "Separate
Precompilations" .
MAXOPENCURSORS specifies the initial size of the SQLLIB cursor cache. If a
new cursor is needed, and there are no free cache entries, Oracle tries to
reuse an entry. Its success depends on the values of HOLD_CURSOR and
RELEASE_CURSOR, and, for explicit cursors, on the status of the cursor
itself. Oracle allocates an additional cache entry if it cannot find one to
reuse. If necessary, Oracle keeps allocating additional cache entries until
it runs out of memory or reaches the limit set by OPEN_CURSORS. To avoid a
"maximum open cursors exceeded" Oracle error, MAXOPENCURSORS must be lower
than OPEN_CURSORS by at least 6.
As your program's need for concurrently open cursors grows, you might want
to respecify MAXOPENCURSORS to match the need. A value of 45 to 50 is not
uncommon, but remember that each cursor requires another private SQL area in
the user process memory space. The default value of 10 is adequate for most
programs.
-----Original Message-----
From: Purushotham [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 25, 2000 12:02 PM
To: [EMAIL PROTECTED]
Subject: Re: Cursors Open problem with multiple insertions
i am using CMP - WebLogic 5.1.0 on Solaris Machine
-----Original Message-----
From: Gene Chuang <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Sunday, September 17, 2000 2:57 AM
Subject: Re: Cursors Open problem with multiple insertions
>Hi,
>
>Calling create on an entity bean home still involves JDBC! But the big
>question now is are you using CMP or BMP, if CMP then what vendor, and
>if
>BMP then what does your ejbCreate method look like. If indeed are
>urgent
>and need answers fast, you need to provide more info!
>
>Gene
>
>-----Original Message-----
>From: A mailing list for Enterprise JavaBeans development
>To: [EMAIL PROTECTED]
>Sent: 9/13/00 10:31 PM
>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".
===========================================================================
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".
