Eek, I goofed on that code change, here's the fixed version:


In:
dada/DADA/App/DBIHandle.pm
Find this line:


       $self->{dbh} = DBI->connect("$data_source", $user, $pass) ||  croak("can't connect to db: $!");


And change it to:


        $self->{dbh} = DBI->connect_cached("$data_source", $user, $pass,  {private_via_process => $$}) || croak("can't connect to db: $!");


Happy Hacking,


--
Justin J.


Dada Mail -  Write Once: Distribute Everywhere Software
url: http://dadamailproject.com


Demo:
http://demo.dadamailproject.com


Seen Dada Mail 3?
http://dadamailproject.com/features/3_0/









On Nov 4, 2008, at 2:07 AM, Justin J wrote:

Alright, I've been hitting my head against this problem for a few  days now. Here's a report:

Sunday, I tried to figure out that whole, "InactiveDestroy" lead I  had. It's a nerdy topic, but basically it has to do with Dada Mail  sending out its mass mailings and needing to connect to the SQL  database from the child it forked, as well as the parent, without  either mucking with the other.

I have no idea how this was working before, but it was, just not  correctly. The hunch was, however the way I was doing it, made the  SQL connections somehow persistent. I guess looking  back, that's  sort of a wild idea, but anyways, I think I've solved the problem  The Right Way,

       2219912 3.0.0 - DBI attribute: InactiveDestroy used incorrectly
https://sourceforge.net/tracker2/?func=detail&aid=2219912&group_id=13002&atid=113002

so I added it as a bug report and committed some changes and fixed  that.  That took all Sunday.

Alongside doing all that, I found some pretty glaring bugs in the  mailing mointor code - a lot of it had to do with when you have to  reload (erm, "restart") a mailing - there's a lot of it that was  broken and I know a lot of people reported this, with the weirdest  bug reports that I couldn't put my head around - things like seeing  that Dada Mail was trying to reload/restart the mailing a few dozen  times without success. I figured out - I think, what was happening  with that, so, again, added a new bug report with an isolated problem:

   2219972         3.0.0 - Mailout.pm - associate method broken
   https://sourceforge.net/tracker2/?func=detail&aid=2219972&group_id=13002&atid=113002


and committed some changes to fix that.

Figuring that, I found a few more problems:

     2219959         3.0.0 - no check to see if mailout exists after sleeping
       https://sourceforge.net/tracker2/?func=detail&aid=2219959&group_id=13002&atid=113002

    2219954 3.0.0 - Guts.pm sub available_lists param, -Dont_Die broken
     https://sourceforge.net/tracker2/?func=detail&aid=2219954&group_id=13002&atid=113002

So that's all good and well, but nothing that I really could see  would cause this problem that Westhost is saying that John has -  namely, that there's 200+ mysql connections.

Dada Mail should be pretty good at reusing the same database handle  again and again, so it doesn't have to make so many connections.  Perhaps 2 or 3 for some really complicated stuff, like sending out a  mass mailing, but nothing more,

*Surely* nothing like 200.

It must be a problem with Westhost. Right? Right. I'm infallible.

But,

but to double-check I turned on Dada Mail's Tracing, to tell me how  me all about it's connections to the Database (and made a little  tweaks to the code) to see how many connections, say, a mailing to  one person takes.

Forty-Nine.


Forty-Nine connections to send one mass mailing message. Add one  more subscriber, get another connection.

Incredible.

Not all these are at the same time, but it's pretty clear there's  room for improvement.

And for the last few hours, I've been banging my head on trying to  get Dada Mail's, "Hey, use the same database handle you already  have!" system to work better. And it's really hard to get better.

And then, I gleaned on this:

       http://search.cpan.org/~timb/DBI-1.607/DBI.pm#connect_cached

Which basically is an easy way to reused database connections.

Yippee.

So, if you have Dada Mail 3.0, try this quick fix, and let me know  how it works for you:

In:

   dada/DADA/App/DBIHandle.pm

find this line:

       $self->{dbh} = DBI->connect("$data_source", $user, $pass) ||  croak("can't connect to db: $!");

And change it to:

        $self->{dbh} = DBI->connect_cached("$data_source", $user, $pass,  {private_via_process => $i}) || croak("can't connect to db: $!");

I know that the word, "Snappy" is used to describe perceived changes  in speed in computer apps, but this change surely will make your  Dada Mail a little, snappier.

To be honest, it's almost like a new program. See if it works for  you (and if it doesn't, let me know)

I'll be releasing a new snapshot with these changes soon,


--
Justin J.

Dada Mail -  Write Once: Distribute Everywhere Software
url: http://dadamailproject.com

Demo:
http://demo.dadamailproject.com

Seen Dada Mail 3?
http://dadamailproject.com/features/3_0/

--

Post: <mailto:dadadev@PROTECTED>

Unsubscribe:
<http://dadamailproject.com/cgi-bin/dada/mail.cgi/u/dadadev/>

List Information: <http://dadamailproject.com/cgi-bin/dada/mail.cgi/list/dadadev>

Archive: <http://dadamailproject.com/cgi-bin/dada/mail.cgi/archive/dadadev>

-- 

Post:
mailto:[list_settings.discussion_pop_email]

Unsubscribe:
http://dadamailproject.com/cgi-bin/dada/mail.cgi/u/[list]/

List Information:
[PROGRAM_URL]/list/[list_settings.list]

Archive:
[PROGRAM_URL]/archive/[list_settings.list]