Re: [jrf-devel] JDBCHelper questions

[Erik T. <ete...@ca...>]

Hi Jonathan,

I don't really have a strong opinion as to the Exceptions in the throws 
clause.  I think there could be a need to act differently based on which 
type of exception is thrown, for example if I do a getConnection() and I 
catch a ClassNotFound exception, my program would be able to provide a 
message indicating there is a classpath issue.   However, I see it's 
awkward having so many Exceptions thrown, and makes it a little more 
difficult to use.. so I could see benefits either way.

I do have to say that I have been largely impressed with the design of JRF, 
I think you made some wise choices.

Here are a couple ideas for you to consider in your refactoring of JDBCHelper:

-Make most, if not all, the private members/methods protected.  I don't see 
a reason JDBCHelper shouldn't be subclassed should someone need to create 
custom functionality.  Also, I would consider removing the 'final' 
constraints within JDBCHelper.
-Refactor the validateConnection method so that each method of obtaining a 
connection is it's own method (i.e. JNDI lookup, driver instantiation, pool).

I actually just ran into an issue this week around this.   If you try to 
retrieve a connection from a weblogic connection pool that doesn't have any 
connections available, Weblogic throws a weblogic.common.ResourceException 
instead of just blocking and waiting for a connection. So I need to write 
code around the connection lookup that will retry a pre-determined amount 
of times and then fail with an exception if it's still unable to get a 
connection.    With the above refactoring ideas I mentioned, creating these 
kinds of custom features would be a little easier.

-Erik


>I want to get some opinions from you.  Maybe you have noticed that many of 
>the JDBCHelper methods have a huge list of exceptions thrown.  I am 
>considering wrapping any non-SQLExceptions in an SQLException (after 
>logging them, of course).
>
>It's always bothered me to have such a huge list in the "throws" clauses 
>of those method signatures.  Especially since some of those exceptions 
>aren't even applicable when accessing the connection via a DataSource 
>(which only throws SQLException when returning a Connection).
>
>Any opinions or thoughts?
>
>Jonathan
>
>P.S. I'm working on refactoring JDBCHelper.  I'll wait to merge with CVS 
>until after Jay gets his stuff into CVS.
>
>
>_________________________________________________________
>Do You Yahoo!?
>Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>_______________________________________________
>jrf-devel mailing list
>jrf...@li...
>https://lists.sourceforge.net/lists/listinfo/jrf-devel