What you are doing will work and may seem simpler than dealing with the
jndi configuration headache in any particular web container or app
server. Here's a few of the things you lose:

1. You have hard-coded the use of a particular database (firebird
rather than oracle e.g.) into your application. With the jndi approach
changing database backends can (assuming your app is portable enough)
be done without touching or recompiling your application. To a lesser
extent this is also the case with which database instance you are
connecting to, although you can set that up using servlet init parms so
you only have to change the web.xml deployment descriptor.

2. Transaction management. You may be able to get by with controlling
transactions on individual connections and restricting the scope of
transactions to a single servlet/jsp page but IMNSHO it is clearer to
use JTA transactions controlled from UserTransaction. This would also
let you migrate to using ejbs and transactions involving more than one
database/resource manager without changing your existing code. Having
said this I must admit that I don't know if Tomcat ships with usable
JTA support: some alternatives that I know do are gluecode JOE and
jetty plus. (gluecode JOE is a packaging of geronimo + jetty that is
pre-set-up and that you can buy support for).

3. Connection pooling. I'm no longer sure which jaybird DataSource
implementations provide connection pooling by themselves :-) However,
most other database's DataSource implementations don't provide
connection pooling. Generally configuring the datasource into jndi
will hook it up to the containers connection pooling implementation.

All this being said... There is a good deal of thought that
applications looking resources up in jndi is not an ideal model and
some suggestions, I think for EJB 3, on alternatives based on various
ideas for dependency injection. (I haven't been following this
discussion very closely). I personally have always had a very hard
time with the tomcat jndi configuration xml although I cannot say for
sure that my efforts at clearer vendor deployment plans have always
been much better.

I'm not sure of the cause of the statement/preparedstatement error you
see.

thanks
david jencks

On Apr 30, 2005, at 8:29 AM, sugi wrote:

> Hello,
>
> Coming from Delphi background, I'm a newbie to Jaybird so please
> excuse
> me if the following questions are RTFM-ish.
>
> Creation Strategy
> =================
> As far as I understand it, Tomcat's preferred method to configure JDBC
> Data Sources is through JNDI. But the steps required to manage this
> is a
> bit painful. If not because of a very helpful post by rfincher2000 to
> this mailing list a while ago, i could never get it to work. Here's
> the
> steps involved;
>
> 1. Copy the jaybird jar files to Tomcat's common\lib directory.
> 2. Create a context configuration file (context.xml) file in the
> WEB-INF
> folder, declaring how to access the database (including username and
> password).
> <Resource name="jdbc/dbTest" auth="Container"
> type="javax.sql.DataSource"
> username="sysdba"
> password="masterkey"
> driverClassName="org.firebirdsql.jdbc.FBDriver"
> url="jdbc:firebirdsql://localhost:3050/c:\\databases\\TEST.GDB"
> maxWait="-1" />
> 3. Add the following items to the application's web.xml.
> <resource-ref>
>      <description>Test SQL DB Connection</description>
>      <res-ref-name>jdbc/dbTest</res-ref-name>
>      <res-type>javax.sql.DataSource</res-type>
>      <res-auth>Container</res-auth>
> </resource-ref>
> 4. Retrieve the DataSource from the application, which involves
> several
> Context lookup calls.
>
> As an aside, I cannot get step #2 above to work in my development
> environment (Eclipse + sysdeo tomcat plugin) so I resorted to hacking
> the actual my_app.xml file in tomcat\conf\catalina\localhost\
> directory.
>
> Anyway, I came across a different approach that I prefer because it
> spares me all the JNDI configuration headache. It involves using one
> servlet as the main controller/dispatcher (i.e. Front Controller).
> Then
> we create an instance of FBWrappingDataSource and add it to the
> servlet
> context (a.k.a. "application" inside JSPs).
>
> ...
> FBWrappingDataSource ds = new FBWrappingDataSource();
> ds.setDatabase("localhost:my_database");
> ds.setUserName("sysdba");
> ds.setPassword("masterkey");
> ds.setIdleTimeoutMinutes(10);
> ds.setPooling(true);
> ds.setMinSize(10);
> ds.setMaxSize(100);
> ...
> ServletContext sc = this.getServletContext();
> sc.setAttribute("datasource", ds);                  
> ...
>
> Inside JSPs, here's the code to get the DataSource instance:
> ...
> DataSource ds = (DataSource) application.getAttribute("datasource");
> Connection c = ds.getConnection();
> ...
>
> So, since the second approach is obviously shorter and easier, is
> there
> any drawbacks/gotchas of using this approach that i should be aware
> of?
> What is the advantage of using the convoluted JNDI approach which is
> probably not portable across containers?
>
> PreparedStatement vs Statement
> ==============================
> After instantiating a FBWrappingDataSource and getting a connection
> from
>   it, Using a plain "Statement" instead of "PreparedStatement" always
> result in "-901 feature not supported" errors. Is this 'normal', or
> am i
> missing something obvious?
>
> Thanks in advance,
> sugi.
>
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
> • To visit your group on the web, go to:
> http://groups.yahoo.com/group/Firebird-Java/
>  
> • To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>  
> • Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service.
>
>