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,