RE: transactional scanner vs regular non transactional scanner?

[Oliver Bucaojit <ol...@esgyn.com>]

Hi Eric,

The transactional scanner is used within a transaction, it will go and
access our transactional state on the server-side to gather the changes made
since the transaction was begun.  The changes are merged with the scan of
the underlying HBase table to get the result.  When a scan is called, and a
transaction ID is not passed in, a standard HBase scanner
(non-transactional) is used.

The transaction type to start with would be the TRX version, that is what's
in use now.

Thanks, Oliver



-----Original Message-----
From: Eric Owhadi [mailto:eric.owhadi@esgyn.com]
Sent: Wednesday, July 29, 2015 1:04 PM
To: dev@trafodion.incubator.apache.org
Subject: transactional scanner vs regular non transactional scanner?

About https://issues.apache.org/jira/browse/TRAFODION-1420

About implementing the small scanner optimization:

Turns out that the small scanner will only work for non-transactional scans
with small work.

Implementing a transactional small scanner is probably possible but is more
work. Before I start investigating transactional small scanner, key question
is to understand when we are using transactional and when we are not? Also
if I started with one transaction type, should it be the Sscc or the Trx
version?

thanks

Eric

Re: transactional scanner vs regular non transactional scanner?

[Sean Broeder <se...@esgyn.com>]

Hi Rohit,
We should be going through the transactional methods for all IDU and select
operations, but we don't currently.  This is a mostly invisible issue when
using the TRX endpoint coprocessor, but it is a major problem for SSCC at
the moment specifically because we do provide snapshots and the results of
the SQL regressions are not what is expected when operations skip the
coprocessor (not transactional).  The non-transactional IDU operations do
present a problem for MVCC for conflict detection and recovery, so I firmly
believe we should have a project to make sure all operations are
transactional so they go through the coprocessor.  For single row, single
region operations we can make these like DP2 transactions so they don't go
through the DTM and incur all the overhead.  I would like to call these
'local transactions', but that term has been commandeered already for
something hat seems more like a client transaction to me.  Maybe we can
work on changing some of the vocabulary around this.

Regards,Sean

On Wed, Jul 29, 2015 at 2:29 PM, Rohit Jain <ro...@esgyn.com> wrote:

> Oliver,
>
> Don't we now force transactional use for all statements? Otherwise, we
> cannot guarantee consistency if some workloads use transactions and
> some don't? Maybe that It's not required for selects as yet, since the
> behavior for selects today would be the same with or without
> transactions, but when we have snapshot isolation that would be necessary.
>
> On Wednesday, July 29, 2015, Oliver Bucaojit <ol...@esgyn.com>
> wrote:
>
> > Hi Eric,
> >
> > The transactional scanner is used within a transaction, it will go and
> > access our transactional state on the server-side to gather the changes
> > made
> > since the transaction was begun.  The changes are merged with the scan of
> > the underlying HBase table to get the result.  When a scan is called,
> and a
> > transaction ID is not passed in, a standard HBase scanner
> > (non-transactional) is used.
> >
> > The transaction type to start with would be the TRX version, that is
> what's
> > in use now.
> >
> > Thanks, Oliver
> >
> >
> >
> > -----Original Message-----
> > From: Eric Owhadi [mailto:eric.owhadi@esgyn.com <javascript:;>]
> > Sent: Wednesday, July 29, 2015 1:04 PM
> > To: dev@trafodion.incubator.apache.org <javascript:;>
> > Subject: transactional scanner vs regular non transactional scanner?
> >
> > About https://issues.apache.org/jira/browse/TRAFODION-1420
> >
> > About implementing the small scanner optimization:
> >
> > Turns out that the small scanner will only work for non-transactional
> scans
> > with small work.
> >
> > Implementing a transactional small scanner is probably possible but is
> more
> > work. Before I start investigating transactional small scanner, key
> > question
> > is to understand when we are using transactional and when we are not?
> Also
> > if I started with one transaction type, should it be the Sscc or the Trx
> > version?
> >
> > thanks
> >
> > Eric
> >
>
>
> --
> Rohit Jain
> CTO
> Esgyn
>

Re: transactional scanner vs regular non transactional scanner?

[Rohit Jain <ro...@esgyn.com>]

Oliver,

Don't we now force transactional use for all statements? Otherwise, we
cannot guarantee consistency if some workloads use transactions and
some don't? Maybe that It's not required for selects as yet, since the
behavior for selects today would be the same with or without
transactions, but when we have snapshot isolation that would be necessary.

On Wednesday, July 29, 2015, Oliver Bucaojit <ol...@esgyn.com>
wrote:

> Hi Eric,
>
> The transactional scanner is used within a transaction, it will go and
> access our transactional state on the server-side to gather the changes
> made
> since the transaction was begun.  The changes are merged with the scan of
> the underlying HBase table to get the result.  When a scan is called, and a
> transaction ID is not passed in, a standard HBase scanner
> (non-transactional) is used.
>
> The transaction type to start with would be the TRX version, that is what's
> in use now.
>
> Thanks, Oliver
>
>
>
> -----Original Message-----
> From: Eric Owhadi [mailto:eric.owhadi@esgyn.com <javascript:;>]
> Sent: Wednesday, July 29, 2015 1:04 PM
> To: dev@trafodion.incubator.apache.org <javascript:;>
> Subject: transactional scanner vs regular non transactional scanner?
>
> About https://issues.apache.org/jira/browse/TRAFODION-1420
>
> About implementing the small scanner optimization:
>
> Turns out that the small scanner will only work for non-transactional scans
> with small work.
>
> Implementing a transactional small scanner is probably possible but is more
> work. Before I start investigating transactional small scanner, key
> question
> is to understand when we are using transactional and when we are not? Also
> if I started with one transaction type, should it be the Sscc or the Trx
> version?
>
> thanks
>
> Eric
>


-- 
Rohit Jain
CTO
Esgyn