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