Hiding connection management completely is actually a good idea.
On Feb 22, 9:51 pm, Christian Catchpole <christ...@catchpole.net>
wrote:
> I think stageful statics are evil. I think ThreadLocal should be cast
> into a large pit and burried. :)
>
> Isn't connection management a non-issue in web containers and even
> stand along apps with a good connection pool. When you open and close
> a connection, you are just borrowing a slot in a pool. There is no
> expense to it. In fact the pool will do clever things such as match
> prepared statements to connections which it has already been prepared
> on.
>
> I'm simply suggesting that you might be able to get away with hiding
> the connection management.
>
> I'm not trying to discourage your work. I have written a persistence
> layer which takes a completely different approach again.
>
> Nice name by the way. :)
>
> On Feb 23, 5:58 am, Christian Hvid <christian.h...@gmail.com> wrote:
>
> > :-D
>
> > Great, exactly.
>
> > This is the point - it removes a lot of code - it is magic - and thus
> > smells of ... air - unless you are used to it.
>
> > You avoid carrying around a JDBC connection object or a reference to
> > something like jdbcTemplate.
>
> > Suppose you write a web application and in your servlet code or page
> > code you have a single try finally block that opens and closes the
> > database connection.
>
> > Within that block you call into your business code and your business
> > code uses various database queries - all against the connection that
> > you manage with the try catch block.
>
> > The reason it is a stack of connections and just one connection - is
> > that a stack allows you to use multiple databases / connections - so
> > this would work:
>
> > public long accountBalance(int accountId) {
> > openConnection("accounting");
> > try {
> > return queryScalar(Integer.class, "select balance from account
> > where id=?", accountId);
> > } finally {
> > closeConnection();
> > }
>
> > }
>
> > int accountId = 27;
>
> > try {
> > openConnection("logging");
> > update("insert into log(account_id, balance) values(?, ?)",
> > accountId, accountBalance(accountId));} finally {
>
> > closeConnection();
>
> > }
>
> > On Feb 22, 7:59 pm, Robert Fischer <robert.fisc...@smokejumperit.com>
> > wrote:
>
> > > Now you've shifted the problem from a plumbing issue to a magical state
> > > issue. This is a major code
> > > smell and complicates the API in nonobvious (to the user) ways.
>
> > > (Of course, I'm the guy who also finalizes his method arguments. So I've
> > > got some wacky opinions
> > > relative to Java norms.)
>
> > > ~~ Robert.
>
> > > Christian Hvid wrote:
> > > > But you can leave it up to the caller to open the connection - meaning
> > > > you just don't open or close any connections.
>
> > > > public int getUserCount() {
> > > > return queryScalar(Integer.class, "select count(*) from people");
> > > > }
>
> > > > And then have the calling code open and close the connection:
>
> > > > openConnection();
> > > > try {
> > > > ...
> > > > getUserCount();
> > > > ...
> > > > } finally {
> > > > closeConnection();
> > > > }
>
> > > > (The idea is that there is a stack of connections and when you do
> > > > something you always use the connection at the top of the stack.)
>
> > > > On Feb 22, 7:24 pm, Robert Fischer <robert.fisc...@smokejumperit.com>
> > > > wrote:
> > > >> The problem is this code:
>
> > > >> public int getUserCount() {
> > > >> openConnection();
> > > >> try {
> > > >> return queryScalar(Integer.class, "select count(*)
> > > >> from people");
> > > >> } finally {
> > > >> closeConnection();
> > > >> }
>
> > > >> }
>
> > > >> That's 1 semantically meaningful line surrounded by 5 lines of
> > > >> boilerplate plumbing. Which means
> > > >> that it's really 1/6th actual code, and 5/6th noise. That's a pretty
> > > >> poor signal to noise ratio.
>
> > > >> It's even worse when you're dealing with raw JDBC calls, since you
> > > >> have to think about preparing
> > > >> statements and managing connections and data sets and the like.
>
> > > >> ~~ Robert.
>
> > > >> Christian Hvid wrote:
> > > >>> I don't understand - why would that be a problem? (That you have
> > > >>> explictly open and close your database connection).
> > > >>> On Feb 22, 7:09 pm, Robert Fischer <robert.fisc...@smokejumperit.com>
> > > >>> wrote:
> > > >>>> +1 for Spring JDBC: it manages all that
> > > >>>> openConnection/closeConnection noise for you, which means
> > > >>>> that your JDBC code can *also* start to be expressive.
> > > >>>> ~~ Robert.
> > > >>>> Rakesh wrote:
> > > >>>>> have you looked at Spring JDBC? It has a similar interface and
> > > >>>>> manages
> > > >>>>> the connections for you.
> > > >>>>> I think if you go down a non-orm route and want to have lots of sql,
> > > >>>>> Ibatis is quite common - not used it so can't say for sure.
> > > >>>>> Spring JDBC though is very nice and have used it extensively.
> > > >>>>> Rakesh
> > > >>>>> On Sun, Feb 22, 2009 at 2:21 PM, Christian Hvid
> > > >>>>> <christian.h...@gmail.com> wrote:
> > > >>>>>> Hi Java people.
> > > >>>>>> I have been toying with simplier ways of doing embedded SQL in
> > > >>>>>> Java.
> > > >>>>>> And would like your comments on this one?
> > > >>>>>>http://code.google.com/p/chalkmine/
> > > >>>>>> It allows you to write code like this:
> > > >>>>>> openConnection();
> > > >>>>>> try {
> > > >>>>>> int count = queryScalar(Integer.class, "select count(*) from
> > > >>>>>> people");
> > > >>>>>> System.out.println("There are "+count+" people in the bin.");
> > > >>>>>> } finally {
> > > >>>>>> closeConnection();
> > > >>>>>> }
> > > >>>>>> or
> > > >>>>>> openConnection();
> > > >>>>>> try {
> > > >>>>>> List<Person> people = queryList(Person.class, "select name,
> > > >>>>>> time_in_the_bin from people");
> > > >>>>>> for (Person p : people)
> > > >>>>>> System.out.println(p.getName()+" has been
> > > >>>>>> "+p.getTimeInTheBin()
> > > >>>>>> +" hours in the bin.");
> > > >>>>>> } finally {
> > > >>>>>> closeConnection();
> > > >>>>>> }
> > > >>>>>> (Provided that Person has a constructor matching the types of name,
> > > >>>>>> time_in_the_bin. Probably Person(String, int).)
> > > >>>>>> Where the methods openConnection, queryScalar, queryList,
> > > >>>>>> closeConnection are statically imported.
> > > >>>>>> openConnection() figures out the name of the calling class, looks
> > > >>>>>> up a
> > > >>>>>> configuration, opens a connection and puts in a ThreadLocal
> > > >>>>>> container.
> > > >>>>>> queryScalar(Class, String, ...) performs a query with a single row
> > > >>>>>> result that is "cast" to the given class.
> > > >>>>>> queryList(Class, String, ...) performs a query and returns the
> > > >>>>>> result
> > > >>>>>> as a list of the given class.
> > > >>>>>> I would like to turn it into a full-fledged open source project.
> > > >>>>>> But since it is incredibly hard for a new open source project to
> > > >>>>>> gain
> > > >>>>>> traction I would like to figure out whether it is interesting
> > > >>>>>> enough
> > > >>>>>> first.
> > > >>>>>> -- Christian
> > > >>>> --
> > > >>>> ~~ Robert Fischer.
> > > >>>> Grails Training http://GroovyMag.com/training
> > > >>>> Smokejumper Consultinghttp://SmokejumperIT.com
> > > >>>> Enfranchised Mind Bloghttp://EnfranchisedMind.com/blog
> > > >>>> Check out my book, "Grails Persistence with GORM and
> > > >>>> GSQL"!http://www.smokejumperit.com/redirect.html
> > > >> --
> > > >> ~~ Robert Fischer.
> > > >> Grails Training http://GroovyMag.com/training
> > > >> Smokejumper Consultinghttp://SmokejumperIT.com
> > > >> Enfranchised Mind Bloghttp://EnfranchisedMind.com/blog
>
> > > >> Check out my book, "Grails Persistence with GORM and
> > > >> GSQL"!http://www.smokejumperit.com/redirect.html
>
> > > --
> > > ~~ Robert Fischer.
> > > Grails Training http://GroovyMag.com/training
> > > Smokejumper Consultinghttp://SmokejumperIT.com
> > > Enfranchised Mind Bloghttp://EnfranchisedMind.com/blog
>
> > > Check out my book, "Grails Persistence with GORM and
> > > GSQL"!http://www.smokejumperit.com/redirect.html
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
