Home > Archive > PERL Miscellaneous > August 2005 > Class::DBI and fork
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Class::DBI and fork
|
|
| golden 2005-08-31, 7:56 am |
| Hi,
I have been using class DBI for generating reports and till now most of
the work has been done off-hours so performance was not quite an issue.
I would now like to have some reports run interactively by a user, but
some of the has_many relationships take a significant amount of time.
So, for my inventory system, I was thinking about taking a list of
products from a user and forking parallell processes for each product
to get all relationships. Each fork would write to a separate file,
then I can reap all the files after completing all products.
The forking was done with Parallel::ForkManager, but when I run the
code, I get all sorts of Errors from Class::DBI, but I do not get those
errors if I remove forking. I suspect that the dbh file handle gets
trashed during the fork.
Can anybody comment or suggest an alternative?
Thanks,
| |
| xhoster@gmail.com 2005-08-31, 6:57 pm |
| "golden" <iang@optonline.com> wrote:
.....
> I would now like to have some reports run interactively by a user, but
> some of the has_many relationships take a significant amount of time.
....
> The forking was done with Parallel::ForkManager, but when I run the
> code, I get all sorts of Errors from Class::DBI, but I do not get those
> errors if I remove forking. I suspect that the dbh file handle gets
> trashed during the fork.
>
> Can anybody comment or suggest an alternative?
The best alternative may be to fix your database. If your database can't
efficiently handle one query at a time, slamming it with multiple queries
at a time is just as likely to make things worse as make them better. YMMV
Each child almost certainly needs it's own connection. So make your
database connections after the fork, rather than before. If you need a
database connection before you do the fork, then close that connection
before the fork, and then reconnect after.
If you need a database connection which survives the fork in only one of
the forked processes, (i.e. because a single transaction spans the fork),
then set InactiveDestroy in every process other than the one that still
needs the handle. (And in general, I believe that the one that keeps the
handle active must be the original process, not one of the spawned ones).
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
|
|
|
|
|