[OSM-dev] [PATCH] Persistant database connection

[Christopher Schmidt]

On Sun, Jul 09, 2006 at 09:16:51PM +0100, SteveC wrote:
> * @ 09/07/06 08:20:00 PM james at mastros.biz wrote:
> > Currently, the core of OSM is a bit silly: Every time it wants to execute
> > some SQL, it connects to the database, runs the sql, gets the entire result
> > set, and then disconnects from the database.  There's a number of ways in
> > which that's silly, but the simplest one is that there's no reason to keep
> > connecting and disconnecting -- connect when you first need the connection,
> > and disconnect when you're all done.
> > 
> > The attached patch touches only a very small amount of code, and will do
> > just that.  There's still plenty of sillyness about, but this will at least
> > pick this piece of low-hanging fruit.
> 
> Sharing one connection, I bet, will be slower than multiple connections.
> If you spend some time using the API you will find that most calls take
> many many times what the tcp set-up cost is.

Right now, each thread is only using one connection at a time. Changing
it so that each instance  is using one connection at a time, but
that that connection lasts for the entire time period that instance is
alive can not decrease performance.

In other words: Each time a new OSM::dao is created, it's possible that
instance will have a dbh handle attached to it for the entire time that
the instance is alive. As soon as it dies, it will go out of scope. You
haven't lost any performance.

> A thread pool would be much better, and something on my todo list. There
> is some example code on the net I was going to integrate... if anyone
> else were to integrate that, it'd be cool

I'm not sure I understand how you think a thread pool would work, but I
think that using a persistent connection for the duration of an OSM::dao
instance would likely be low hanging fruit which could later be
augmented by such a thread pool.

Can you explain where I'm wrong please?

-- 
Christopher Schmidt
Web Developer