Hi Jacob, Thanks for the response!
> I know this isn't what you want to hear but.. > > PHP is an absolutely awful language when it comes to doing anything > but web-related work. Well, it's not the language per-se, it's the > runtime. Even if you figure out how to get your database connections > reconnected you will run into problems with the PHP garbage > collector. You will have memory leaks that are impossible to fix. > You'll end up coding a script to watch your script. That's good point. I hadn't really considered the memory angle and I'm not opposed to just implementing it in Java. The only issue that kinda, hurm, sucks, is the issue of bypassing my primary persistence layer (Propel). My attempt to code it in PHP was just to keep things in PHP... The idea of having a batch script doing an external task was just a bit too tantalizing, I suppose. But on the plus side, I can ditch FAM, since Java has built in classes for this sort of thing. Some of the processing was in Java anyway, on account of the fact that I'm processing images and Java has superior support for doing non- trivial image manipulation. > Beyond that, you could extend sfPropelDatabase with your own database > class that reconnects before returning. You (should) just need to > override the getConnection() method. You can specify the connection > class in databases.yml. I was afraid of that. Not that I'm opposed to extending the class, it just seems like I'd get getting into somewhat unsupported territory. Back to the drawing board. That's for the memory issue comment -- that has doubtfully helped saved me a great deal of troubleshooting down the road. Best, JLS On Feb 4, 2009, at 6:15 PM, Jacob Coby wrote: > > > On Feb 4, 2009, at 7:51 PM, John L. Singleton wrote: >> The issue is that the next_fam_event call blocks indefinitely. If PHP >> had threads, I could easily just keep a connection alive in the >> background, but alas, it doesn't. My other option (of course) is to >> switch to a polling method, but that wastes CPU and database >> resources. This is a fairly common pattern which I've used countless >> times in other languages... Also, async JMS messaging generally works >> something like this, only you specify callbacks to handle events and >> so on. I just can't find a way to make it work with Symfony. But >> thanks so much for responding! > > I know this isn't what you want to hear but.. > > PHP is an absolutely awful language when it comes to doing anything > but web-related work. Well, it's not the language per-se, it's the > runtime. Even if you figure out how to get your database connections > reconnected you will run into problems with the PHP garbage > collector. You will have memory leaks that are impossible to fix. > You'll end up coding a script to watch your script. > > If you have anything that needs to run as a daemon or is memory- > sensitive or needs to process large amounts of data quickly, use a > language better suited to the task. > > With that out of the way, here are some ideas that may or may not > work: > > $dbm = sfContext::getInstance()->getDatabaseManager(); > $dbm->shutdown(); > $dbm->initialize(); > > At least then you're dealing with the same object that sf uses > internally. > > Beyond that, you could extend sfPropelDatabase with your own database > class that reconnects before returning. You (should) just need to > override the getConnection() method. You can specify the connection > class in databases.yml. > > -- > Jacob Coby > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" 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/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
