Collectors versus Flow.Subscriber

Alexander Kjäll alexander.kjall at gmail.com
Tue May 1 15:28:49 UTC 2018


Thanks for the input, It was valueble.

I hadn't realized that doing a vendor extension was so easy for the user,
it looks like the correct approach to solve this.

best regards
Alexander Kjäll
Den tis 1 maj 2018 kl 16:58 skrev Douglas Surber <douglas.surber at oracle.com
> :

> If it is a row sequence then a RowProcessorOperation should be exactly
what you need.

> Douglas

> > On May 1, 2018, at 4:09 AM, Alexander Kjäll <alexander.kjall at gmail.com>
wrote:
> >
> > It can maybe be thought of as an row sequence with one row per event,
and
> > it should be possible to be represented as a RowOperation.
> >
> > But I was more thinking about back pressure, the collector interface
> > doesn't really allow the implementation to signal to the driver that it
> > can't handle the rate of traffic, and a busy event generator might
> > overwhelm the consumer. This might maybe be a problem with normal
queries
> > also?
> >
> > I haven't done any testing of this, and I don't have any concrete code
that
> > demonstrates the problem. I can revisit this topic later when I have
> > something more concrete to show and talk about.
> >
> > best regards
> > Alexander Kjäll
> >
> > Den mån 30 apr. 2018 kl 18:06 skrev Douglas Surber <
> > douglas.surber at oracle.com>:
> >
> >> We haven’t discussed much aside from ANSI SQL. I don’t know anything
> > about postgresql logical decoding. Is it a row sequence? If so then
either
> > RowOperation or RowProcessorOperation should do fine. If it returns a
> > result that doesn’t map to an ANSI SQL result then it would require a
> > vendor specific extension.
> >
> >> Douglas
> >
> >>> On Apr 28, 2018, at 1:21 PM, Alexander Kjäll <
alexander.kjall at gmail.com>
> > wrote:
> >>>
> >>> Hi
> >>>
> >>> I have been poking around writing an implementation of ADBA for
> > postgresql
> >>> and have a question regarding how 'endless' datastreams should be
> > handled.
> >>>
> >>> To take a concrete case is the feature in postgresql that's called
> > logical
> >>> decoding, it lets a user subscribe to the replication stream from the
> >>> database.
> >>>
> >>> This isn't a stream that has an end, and by that account it doesn't
> > really
> >>> in the stream model with collectors and would maybe fit better with
the
> >>> Flow.Subscriber model.
> >>>
> >>> Have this usecase been considered and is there a way to implement this
> > that
> >>> I haven't seen?
> >>>
> >>> best regards
> >>> Alexander Kjäll


More information about the jdbc-spec-discuss mailing list