Re^2: faster with threads?

One thing to watch out for is DBI thread/fork safe?

I seem to recall having problems with database connections 'going away' when using database handle inside forked off child processes. I resolved this by each child process recreating it's own database handle.

Another thing to watch is maybe if the DB and log reside on the same disk then you could have decreased performance if doing major I/O on both at once, Hence maybe try and read the whole log into memory

Comment on Re^2: faster with threads?

Replies are listed 'Best First'.
Re^3: faster with threads? by etcshadow (Priest) on Jun 09, 2004 at 19:18 UTC
The issue with DBI and forking is this: You need to set `$dbh->{InactiveDestroy} = 1` in all of your child processes. Otherwise, when one child process dies it may kill database connections in other processes. (This is because as part of the DESTROY for the handle, it tells the databse server that it is done with the connection... even if there's another process that is not done with it) Also be warned of the greater conceptual issue that you can only use a DB connection in one process. The connection may exist in other processes (hence the warning above about setting InactiveDestroy), but it can only be used in one. Also, no, DBI is not threadsafe (unless this has changed recently... and that would be a big deal). `------------ :Wq Not an editor command: Wq` [download]	[reply] [d/l] [select]
Re^3: faster with threads? by necroshine (Acolyte) on May 09, 2008 at 20:47 UTC
Necroshine Well, I've tried to solve this with this concept, and doesn't work for me. After a some time, the connections was broken and the process stays inactive. Why? Cheers!	[reply]


good chemistry is complicated, and a little bit messy -LW
	PerlMonks