Richard-
See below:

> -----Original Message-----
> From: Richard Harnden [mailto:richard.harnden@lineone.net]
> Sent: Thursday, February 02, 2006 4:08 AM
> To: informix-list@iiug.org
> Subject: Re: Another IDS Feature Request
>
> Madison Pruet wrote:
> > "Art S. Kagel" <kagel@bloomberg.net> wrote in message
> > news:43E0E317.2080907@bloomberg.net...
> >
> >>bozon wrote:
> >>
> >>>Art S. Kagel wrote:
> >>>
> >>>
> >>>>bozon wrote:
> >>>>
> >>>>
> >>>>>It would help us. I think it would be a feature that would really
fit
> >>>>>in with the new redundant fault tolerant application structure
that
> is
> >>>>>popular today.
> >>>>
> >>>><SNIP>
> >>>>
> >>>>That raises an additional, related request. That the global
cursor ID
> >
> > be
> >
> >>>>sharable across ER replicants. That would allow cost free
failover to
> a
> >>>>backup server!
> >>>>
> >>
> >>By George I think he's got it!
> >>
> >
> > Ain't gonna happen...
> >
> > The main purpose of a Cursor is to keep a pointer into the table as
the
> rows
> > are being processed.
> >
> > Since ER doesn't enforce the physical placement of the data, then a
> cursor
> > on one server is meaningless on another.
> >
> > In fact Since ER is selective in what is replicated, we can't
guarentee
> that
> > the query plans on differing nodes will be the same....
> >
> > M.P.
> >
> >
>
> All that I'd want would be the ability to suspend an active session,
> disconnect, reconnect and then awaken the suspended session - exec it,
> iow. So that the session, if you like, goes from cond_wait(netnorm)
to
> cond_wait(http_norm) and back again.

You would have a very hard time convincing any competent
programmer to implement this strategy, since if the suspended never
reconnected and closed, it would leave the suspended session just
hanging there. This would have the effect of deliberately introducing a
memory leak into the system. At the very least the suspended session
would have to time out, allowing the resources to be freed and reused.
Any program trying to reconnect would then hang or fail.

--EEM

>
> --
> rh
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list

Everett Mills wrote:
> I wrote:
>
>>All that I'd want would be the ability to suspend an active session,
>>disconnect, reconnect and then awaken the suspended session - exec it,
>>iow. So that the session, if you like, goes from cond_wait(netnorm)
>
> to
>
>>cond_wait(http_norm) and back again.
>
>
> You would have a very hard time convincing any competent
> programmer to implement this strategy, since if the suspended never
> reconnected and closed, it would leave the suspended session just
> hanging there. This would have the effect of deliberately introducing a
> memory leak into the system. At the very least the suspended session
> would have to time out, allowing the resources to be freed and reused.
> Any program trying to reconnect would then hang or fail.

Ah, ye olde "distributed oh sorry I went to lunch and forgot" attack.

Of course you'd want it to timeout. I asked for that upthread already.

--
rh