Find a GOOD book on Java programming and patterns. Putting database
access in your JSP puts you well on the way to being stuck with an
unmaintainable application, as you're mixing your presentation and data
layers. If the database changes, you need to chase down all the queries
you've embedded in your JSPs.
Create a DAO (see any Java patterns book, such as Core J2EE Patterns by
Alur et al), and have it manage connections transparently for you. Have
the servlet call into the DAO and then place the data in the request
context, and have the JSP then get the data out of the request context
for display.

-----Original Message-----
From: Firebird-Java@yahoogroups.com
[mailto:Firebird-Java@yahoogroups.com] On Behalf Of sugi
Sent: Saturday, April 30, 2005 11:29 AM
To: firebird-java@yahoogroups.com
Subject: [Firebird-Java] Using FBWrappingDataSource

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