Thanks for the detailed answer. You're right, what I need is a
straightforward connection pool, configurable via the container (in this
case tomcat).
On Sat, Jan 3, 2009 at 4:44 PM, Will Hartung <[email protected]> wrote:
>
> 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
>
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
