postgres wont do preparedstatements

[Paul J Stevens]

Jan-Henrik Haukeland wrote:
> Okay, thanks we'll look into it.
> 
> A couple of comments to http://git.dbmail.eu/?p=paul/dbmail;a=shortlog;h=zdb 
> ..

Thanks for taking some time to look at my code. You're quite correct about all
those globals. That code branch is very much work in progress. Up until very
recently dbmail used a preforking model, with a single connector per process.
However, with many concurrent client connections (mostly imap) that model was no
longer tennable. So I refactored the server code last month to use libevent
within a single process. This scales much better for network io and now the
database io then became the main bottleneck.

Ultimately (code complete before the summer) plan is:

- replace the homegrown database modules with a generic layer (libzdb) still
using a single connectionpool/connector/resultset etc. That is what I'm working
on atm.
- next, refactor the database layer to use local connections and result sets, so
we can pull a connection from the pool and return it once we're done with it.
- finally, start doing the command processing in threads so the database calls
don't block the main thread anymore.

I expect and hope that by combining libevent and libzdb we'll achieve quite an
interesting potential for scaling up the imap server. Both represent very
exciting technologies that fit very well with what I'm trying to do.

After the above milestones have been completed, and if sponsoring is found we
might even add multiple connection pools in the mix so different imap users are
mapped to different database backends.


> - We could add a Connection_vexecuteQuery(T C, const char *sql,  
> va_list ap) if you want to save those snprintf() calls to build the  
> query and instead call executeQuery directly in the facade function  
> db_query(), or you could skip the facade and call  
> Connection_executeQuery() directly.

Thanks for the offer. I'll give it some thought.

> 
> - If you compiled libzdb with exception (highly recommended) you need  
> to enclose calls that can throw an exception, (basically all methods  
> in Connection, PreparedStatement and ResultSet), in a try-catch  
> statement. Below is an example of a mini-framework we use with libzdb  
> and where we isolate database call and exception testing to a Service  
> function, which may be helpful to take a look at.

I'll make sure the debian packages are build with exceptions and protected. And
I definitely plan on leveraging exceptions in dbmail.


-- 
  ________________________________________________________________
  Paul Stevens                                      paul at nfg.nl
  NET FACILITIES GROUP                     GPG/PGP: 1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl