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