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