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 -~----------~----~----~----~------~----~------~--~---
