Page 1 of 1

Lazy loading your database connection...

Posted: Thu Aug 25, 2005 11:24 pm
by nielsene
Normally I wouldn't think of making a thunk out of the database connection code, but for some reason it keeps creeping into my thoughts here.

Given:
1. Almost every valid request will need a database connection
2. Almost every authorization checked will require a DB connection
3. A fraction of invalid requests require a database connection to check the invalid status
(This happen in inverse order, of coursse)

BUT,
1. All legacy pages (currently 99% of the site) will show up as an invalid request that gets retried under the legacy handler
2. Legacy pages will create their own DB connections -- leading to double connections on most pages during the transition
3. Most legacy pages will fail the initial handling without requiring a database connection

Would you use lazy-loading on the database connection?

Posted: Sat Aug 27, 2005 12:46 pm
by McGruff
On the principle of one handler per page, what I've been doing is to attempt to make the db conn in an individual "DbUnavailable" handler. This stops the script and displays an error if a connection cannot be made.

Lazy-loading probably isn't very useful for a db conn in most cases. If there were various logical paths a script might go down some of which don't require a db, it might be. However it's usually fundamental to the operation of a script and I like to get that out of the way early on.

Posted: Sat Aug 27, 2005 6:09 pm
by Buddha443556
Lazy-loading probably isn't very useful for a db conn in most cases. If there were various logical paths a script might go down some of which don't require a db, it might be. However it's usually fundamental to the operation of a script and I like to get that out of the way early on.
What I'm working on most be the exception that proves McGruff assertion but lets not go there ... :D

Since your converting to a new system and this system seems, from what you've told us, to require a database connection - I say load it if you think the database can take it. Eventually you'll be back to one database connection once your legacy code is assimilated. Right? When your back to one connection then you might give more thought to lazy loading.

Posted: Sat Aug 27, 2005 6:48 pm
by nielsene
No, I'll have two database connections for the foreseeable future. But I think I found a working solution that doesn't feel too wrong to me.

I found a way to delay the creation of the second database connection until after the common failure conditions.

(One database connection goes to a "Central" database that basically powers a Portal style infrastructure. The other database connection is open to a per-event satellite database. I host registration for ~20 competitions a year, each competition lives in its own database. (That was another legacy situation -- the application started out only as the registration code for a single competition, with the thought that all the schools would run their own site locally. However that didn't quite work out, so its evolved to me hosting everyone. Now this makes lots of other nice features possible, but.... migrating the satellite DB's into the central, adding new columns where needed to keep the competitions separate and re-syncing the ORM is a fairly large undertaking. Its on the agenda for after I transiation to the new infrastructure and round out a few of the high priority missing featuress.)

Posted: Sat Aug 27, 2005 7:57 pm
by sweatje
Since you happen to own my book, you could look at the Proxy chapter for an example of using the Proxy pattern to handle lazy loading. :)

If you are using some kind of a factory to get your database connection, all you have to do is change that factory to return a lazy loading proxy instead of the live connection, and then you should have no downstream code to change to realize the benefit of lazy loading.