Re: Re[2]: [PATCH] Sqlite DB Pool

It's a pretty good alternative for people with low traffic, for "proof  
of concept" projects and also for embedded appliances where memory is  
limited and a regular db engine wouldn't fit.

Besides, I'm using the DBPool already implemented into Kannel and  
trying to implement the same DB engines as Kannel does, so people  
using sqlite for dlr's can use it for sqlbox as well.

Regards,

Alejandro Guerrieri

El 20/11/2008, a las 12:27 p.m., Thomas Göttgens escribió:

> Hello Alejandro,
>
> just out of curiousity, why do we bother with SQLITE anyway? It's
> clearly designed for light usage, especially within web applications,
> mostly db ready, maybe a few writes.
>
> This can for sure not sustain even light usage from kannel. Sqlite is
> essentially a file database like dbase with an sql frontend.
>
> Thursday, November 20, 2008, 2:40:33 PM, you wrote:
>
> AG> Alex,
>
> AG> Sqlite makes a lock on the _whole DB file_ each time it access it.
> AG> That means that if an external application is doing an INSERT on
> AG> send_sms, it will lock the WHOLE FILE, so sqlbox won't get a  
> LOCK to
> AG> DELETE on send_sms nor to INSERT on sent_sms.
>
> AG> If the DB is to sustain moderate load, the default won't cut it.  
> I've
> AG> experienced the error when trying to enqueue messages from  
> Sqlite's
> AG> command line utility while running sqlbox. I'm talking about  
> sending a
> AG> _single_ message on an idle sqlbox process.
>
> AG> Using the default "busy_timeout" is too low for most practical  
> uses
> AG> IMHO.
>
> AG> For example, the PHP driver sets it to 60 seconds.
>
> AG> If not allowed to change it on the DBPool, it should be set to  
> some
> AG> more realistic value at least, or maybe even set a default and  
> allow
> AG> the client to change it (I can modify the patch to accomodate  
> either
> AG> case of course).
>
> -- 
> Best regards,
> Thomas                            mailto:[email protected]
>