On Jan 1, 2009, at 9:31 AM, M S wrote:
> I have a very simple web app to develop - just a few pages that
> display formatted results of queries against a preexisting
> database. I'm trying to pick a java framework to use while
> developing this, and I'm attracted to stripes because of its
> apparent simplicity.
>
> I was hoping that stripes would somehow handle the database
> connections for me (including pooling, configuration, etc.), but
> that doesn't seem to be the case. Using something like hibernate
> is overkill for such a small project (perhaps if I had already used
> hibernate in the past, I would use it now too, but at this point I
> can't justify spending so much time learning it for such a simple
> app).
>
Yea, Stripes isn't a "full stack", and thus doesn't have anything
(stock) to handle things like the database connections, etc.
> So my question is - how do you handle database connection in your
> stripes webapp? Where do you create the connection and which
> classes include your sql queries?
>
For database pooling, I'd punt to the container and let it deal with
it. All of the servlet containers can be configured to deliver
DataSource objects via a JNDI lookup, and, that's what I would use
for the actual to get the actual connections.
e.g.
Context c = new InitialContext();
DataSource ds = c.lookup("java:comp/env/jdbc/yourdb");
Connection con = ds.getConnection();
The only reason to worry about "sharing" connections (well, the
primary reason) is to run multiple blocks of SQL in different
routines but all within the same transaction.
But, in truth, for most simple applications, this isn't necessary.
Most simple applications work with the good ol' standby:
Connection con = getConnection();
con.setAutoCommit(false); // assuming getConnection doesn't do this
for you -- though it should
... bla bla bla ...
con.commit();
con.close();
By using a connection pool, that alone takes care of the primary need
to "worry about connections" and not simply grab one when you want,
use it, commit it, and close it. Creating the Connection is the most
expensive part.
After that, it's transaction consistency.
And the trivial way to mitigate that is simply pass the Connection
around to those units involved in the same transaction. If most of
your DB work is self contained, then that's not even an issue. I
mean, heck, that's what Spring does, right? It simply uses the
framework to inject its Connection in to the appropriate beans, no
reason you can do that either.
ServiceBean b = new ServiceBean(myConnection);
b.doService();
Nothing mystical or magic there.
Now, a lot of folks that do use hibernate and what not like to set up
Connections in thread locals set up by Filters to handle the auto-
creation and auto-commit etc as the request comes in to the container.
It's a viable and useful technique, but it does add complexity, and
"stuff behind the scenes".
So, if your app is simple, you can just keep it simple.
Finally, of course, the simplest of abstractions can future proof
your code no matter how you go. Using a simple home grown
"ConnectionFactory" gives you a nice single point of entry for all of
your Connection management. Even to the point of injecting a custom
Connection implementation that wraps the container provided
connection, but lets you intercept things like the "commit" statement
to delegate it later.
The beauty, of course, is you don't have to do any of that today. You
can do it later if your "simple app" gets more complicated.
So, simply, beyond getting a Connection pool set up (and each
container should make this straightforward), for a simple
application, I wouldn't over think it. Using simple abstractions
(like a home grown connection factory) will let you keep your options
open going in to the future.
Regards,
Will Hartung
------------------------------------------------------------------------------
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
