I guess I wasn't very clear. The component is being kept alive by the use of
an alias. The session which posted to the component keeps stopping before the
component can post back to it. So my problem isn't that the component is dying
prematurely but the session who is requesting something from the component. I
don't have any reason to store a postback immediately because their are a
couple of different postback()'s that can be created and called depending on
what happens in the component itself. The only reasonable way to keep the main
session, not the component, alive is to increment the sender's ref count in the
component. How are session which are using components expected to stay alive?
[EMAIL PROTECTED] wrote:
> On Thu, Jul 19, 2001 at 11:53:42AM -0700, Todd Caine wrote:
> > I just need some clarification. When writing a
> > POE::Component. If the POE Session using the component just
> > starts up and posts an event to the component, the only way
> > for the Session to remain alive long enough to receive a
> > postback is by either incrementing the SENDER's refcount and
> > then decrementing it after we do the postback, or by storing
> > the postback into the heap.
> >
> > In the Component that I'm trying to write I'm using
> > $_[KERNEL]->refcount_increment($_[SENDER]->ID, 'keep_alive')
> > in the state that's being posted to. If I postback to the
> > SENDER in the same state and decrement the SENDER's refcount
> > then the SENDER stays alive long enough to get the
> > postback. If I don't post immediately back to the SENDER
> > but still have the SENDER's refcount incremented shouldn't
> > the SENDER stay alive until I decrement the refcount?
>
> I would suggest either using an alias or use postbacks. Incrementing the
> refcount manually doesn't seem to be very clean. Aliases and postbacks
> increment the extra ref count. If you want to keep the component alive
> and you don't want to use postback or selects and events in the queue won't
> to the job, write something that hands out postbacks to your component,
> through which clients talk to it.
>
> I wrote such a thing some time ago i think. It works like an directory
> service where you can register postbacks under a specific name and
> interested clients can get a copy of the postback. you can implement
> singletons or different instances per postback. however i never
> completed it (its not a lot anyway), since i though it would be better to
> do it right and write an object layer someday :)
>
> Torvald
--
/*
* Todd Caine
* Software Engineer
* Electric Lightwave, Inc.
* [EMAIL PROTECTED]
* (360) 816-4344
*/
