I agree the EasyDBI is the way to go for this.  I ended up hacking
EasyDBI SubProcess to ensure that all the statements are finished and
the disconnect is called so that resources on the database side  are
not consumed.

On Dec 14, 6:51 am, [EMAIL PROTECTED] (Philip Gwyn) wrote:
> On 14-Dec-2007 Daisuke Maki wrote:
>
> > Hi,
>
> > I might just be missing something obvious, is there anyway to tell if an
> > object being accessed via POE::Component::Generic is dead?
>
> Short answer : your code should never die!
>
> Looking at my code, it seems that POE::Component::Generic doesn't handle dead
> child processes very well.
>
> Unless you wish to modify PoCo::Generic (patches welcome!), you could you'll
> have to overload the __wheel_close().   Roughly :
>
>     package My::Generic;
>     use base qw( POE::Component::Generic );
>     sub __wheel_close {
>         my( $self, $wheel_id ) = @_[ OBJECT, ARG0 ];
>         # your code here
>         $_[KERNEL]->post( $your_session, 'respawn_event', ... )
>
>         $self->SUPER::__wheel_close( @_ );
>     }
>
> > Basically, I'd like to wrap things like DBI access and such underneath
> > PoCo::Generic, but at the same time I'd like to detect when, for
> > example, a DBI connection is lost, or perhaps the child process that is
> > wrapping DBI is killed.
>
> You might want to look at POE::Component::EasyDBI, from which
> POE::Component::Generic is a philosophical descendent.  It handles gracefully
> restarting the child process if it dies, something that 
> POE::Component::Generic
> never will.
>
> -Philip

Reply via email to