Thanks Achipa.
On Mar 2, 6:17 am, AchipA <[email protected]> wrote:
> The non-pooled models now disconnect after page serve and the pooled
> ones stick around, so I guess it's OK. Tested only with mysql though,
> YMMV.
>
> On Mar 1, 7:13 pm, mdipierro <[email protected]> wrote:
>
> > GRRRRRRR!
>
> > You are be right. This can happen and it is a bug in web2py. I think I
> > fixed it.
> > Can you please try the latest trunk?
>
> > Massimo
>
> > On Mar 1, 11:11 am, AchipA <[email protected]> wrote:
>
> > > Then I have a spotted a bug. After serving a page, if I do a "mysql -
> > > uroot -e 'show processlist'" after the page has been served I
> > > invariably see a webpy connection(s) in sleep mode (and it stays there
> > > until it times out or another page request happens). Not sure if this
> > > is mysql specific or that maybe I messed up something in my particular
> > > install, will try to make a more thorough test tomorrow.
>
> > > mdipierro wrote:
> > > > this "web2py never closes a database connection" is not true. web2py
> > > > closes all connections per thread when the page is served.
> > > > If you find circumstances when this is not true let me know the
> > > > details because I'd consider it a bug.
>
> > > > On Mar 1, 9:51 am, AchipA <[email protected]> wrote:
> > > > > Another question when we are talking about pooling. Would it be
> > > > > possible to have a keepalive(=True by default to be backward
> > > > > compatible) parameter ? My beef is that when you have several web2py
> > > > > processes (especially you are connecting to a database which is not
> > > > > local) it is very easy to amass enough connections to run into the
> > > > > dreaded 'too many connections' problem as web2py never closes a
> > > > > database connection. Pools only exacerbate this problem as they are
> > > > > per process.
>
> > > > > On Mar 1, 4:28 pm, mdipierro <[email protected]> wrote:
>
> > > > > > OK with the last suggestion.
> > > > > > Uploading to trunk now. Thanks Markus.
>
> > > > > > On Mar 1, 9:19 am, Markus Gritsch <[email protected]> wrote:
>
> > > > > > > On Sun, Mar 1, 2009 at 4:05 PM, mdipierro
> > > > > > > <[email protected]> wrote:
>
> > > > > > > > You are right but we need to keep backward compatibility.
>
> > > > > > > > read pools as pool s. = pool size
>
> > > > > > > Well, IMO backward campatibility cannot be used in this case to
> > > > > > > justify a misleading API. The parameter 'pools' is not
> > > > > > > documented in
> > > > > > > the book andhttp://mdp.cti.depaul.edu/AlterEgo/default/show/169
> > > > > > > explicitly says "At this point the feature works but it has to be
> > > > > > > considered experimental and more tests are welcome."
>
> > > > > > > So IMO it should be possible to change the API before it is
> > > > > > > officially
> > > > > > > documented. And even if this is not the case, maybe it would be
> > > > > > > possible to keep 'pools' for backwards compatibility and add a new
> > > > > > > parameter called 'pool_size' which gets officially documented.
>
> > > > > > > Markus
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
