Subject | Using FBWrappingDataSource |
---|---|
Author | sugi |
Post date | 2005-04-30T15:29:15Z |
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.
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.