Paging Mike Matrigali

[Rick Hillegas <Ri...@Sun.COM>]

Hey Mike,

Can you shed some light on this issue? Can the Store layer walk 
backwards through an index? Or do you have to reposition by key and then 
inch forward again?

Thanks,
-Rick

Re: Paging Mike Matrigali

[Satheesh Bandaram <sa...@Sourcery.Org>]

While you are correct that SCROLL SENSITIVE resultsets will involve many
changes, it should be possible to implement SCROLL INSENSITIVE easily.
JDBC does allow updating INSENSITIVE resultsets and Dag has already
pointed out other differences in previous postings. I also suspect many
database vendors provide support for INSENSITIVE only for the reasons
you listed here.

Satheesh

Mike Matrigali wrote:

> The current store layer does not support scrolling backward through
> a btree (I would say that supporting scrolling backward through a
> heap makes no sense, as the heap provides absolutely no guarantee of
> order).
>
> I would say it is a medium project to provide such a feature.  The
> pointers exist, but the coding is not as simple as just going backward.
> The latch/latch deadlock protocol requires that latches in a btree only
> be obtained top/down, left/right.  If you have to wait for a latch while
> going backward then in the worst case you may have to give up all your
> latches, wait and do a complete new search of the tree as your key
> may have moved unpredictably through the tree. I don't think it applies
> but derby does support ascending and descending key indexes so one
> can always create a "forward" index that actually provides the backward
> direction you are looking for.
>
> There may be some dependencies in the various isolation levels that
> may also need to be addressed - ie. previous key locking probably needs
> different scan implementation in backward vs. forward.
>
> Also harder would be to change the existing interfaces to be able to
> go forward and then back, most of my comments apply to just going in
> a single direction.  Language can also current ask for prefetch
> internal to the scan (it exists between store and language) - so there
> may be multiple layers of prefetch going on.
>
> Having said all that, I thought all of the updatable result set stuff
> was implemented way above store -- I am definitely not an expert in this
> stuff.  Store
>
> Rick Hillegas wrote:
>
>> Hey Mike,
>>
>> Can you shed some light on this issue? Can the Store layer walk
>> backwards through an index? Or do you have to reposition by key and
>> then inch forward again?
>>
>> Thanks,
>> -Rick
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: updatable resultSet
>> From:
>> "Dag H. Wanvik" <Da...@Sun.COM>
>> Date:
>> Tue, 11 Oct 2005 18:12:41 +0200
>> To:
>> Dag.Wanvik@Sun.COM
>>
>> To:
>> Dag.Wanvik@Sun.COM
>> CC:
>> Derby Development <de...@db.apache.org>, mikem_app@sbcglobal.net
>>
>>
>> Hi,
>>
>> I notice the current forward only, updatable implementation does not
>> do prefetch from the network client driver, hence removing a need to
>> move backwards when perfoming an update in the middle of a prefetch
>> set.
>>
>> It seems a main problem with implementing scrollable sensitive result
>> sets is being able to scan backwards (both heap and btree). Can
>> somebody cast some light on what, if any, underlying assumptions would
>> make this hard?
>>
>> Mike, can you comment on this perhaps?
>>
>> Thanks,
>> Dag
>
>
>
>

Re: Paging Mike Matrigali

[Mamta Satoor <ms...@gmail.com>]

Yes, you are right. The forward only updatable resultset was implemented
over existing store layer.
 Mamta

 On 10/12/05, Mike Matrigali <mi...@sbcglobal.net> wrote:
>
> The current store layer does not support scrolling backward through
> a btree (I would say that supporting scrolling backward through a
> heap makes no sense, as the heap provides absolutely no guarantee of
> order).
>
> I would say it is a medium project to provide such a feature. The
> pointers exist, but the coding is not as simple as just going backward.
> The latch/latch deadlock protocol requires that latches in a btree only
> be obtained top/down, left/right. If you have to wait for a latch while
> going backward then in the worst case you may have to give up all your
> latches, wait and do a complete new search of the tree as your key
> may have moved unpredictably through the tree. I don't think it applies
> but derby does support ascending and descending key indexes so one
> can always create a "forward" index that actually provides the backward
> direction you are looking for.
>
> There may be some dependencies in the various isolation levels that
> may also need to be addressed - ie. previous key locking probably needs
> different scan implementation in backward vs. forward.
>
> Also harder would be to change the existing interfaces to be able to
> go forward and then back, most of my comments apply to just going in
> a single direction. Language can also current ask for prefetch
> internal to the scan (it exists between store and language) - so there
> may be multiple layers of prefetch going on.
>
> Having said all that, I thought all of the updatable result set stuff
> was implemented way above store -- I am definitely not an expert in this
> stuff. Store
>
> Rick Hillegas wrote:
> > Hey Mike,
> >
> > Can you shed some light on this issue? Can the Store layer walk
> > backwards through an index? Or do you have to reposition by key and then
> > inch forward again?
> >
> > Thanks,
> > -Rick
> >
> > ------------------------------------------------------------------------
> >
> > Subject:
> > Re: updatable resultSet
> > From:
> > "Dag H. Wanvik" <Da...@Sun.COM>
> > Date:
> > Tue, 11 Oct 2005 18:12:41 +0200
> > To:
> > Dag.Wanvik@Sun.COM
> >
> > To:
> > Dag.Wanvik@Sun.COM
> > CC:
> > Derby Development <de...@db.apache.org>, mikem_app@sbcglobal.net
> >
> >
> > Hi,
> >
> > I notice the current forward only, updatable implementation does not
> > do prefetch from the network client driver, hence removing a need to
> > move backwards when perfoming an update in the middle of a prefetch
> > set.
> >
> > It seems a main problem with implementing scrollable sensitive result
> > sets is being able to scan backwards (both heap and btree). Can
> > somebody cast some light on what, if any, underlying assumptions would
> > make this hard?
> >
> > Mike, can you comment on this perhaps?
> >
> > Thanks,
> > Dag
>
>

Re: Paging Mike Matrigali

[Mike Matrigali <mi...@sbcglobal.net>]

The current store layer does not support scrolling backward through
a btree (I would say that supporting scrolling backward through a
heap makes no sense, as the heap provides absolutely no guarantee of
order).

I would say it is a medium project to provide such a feature.  The
pointers exist, but the coding is not as simple as just going backward.
The latch/latch deadlock protocol requires that latches in a btree only
be obtained top/down, left/right.  If you have to wait for a latch while
going backward then in the worst case you may have to give up all your
latches, wait and do a complete new search of the tree as your key
may have moved unpredictably through the tree. I don't think it applies
but derby does support ascending and descending key indexes so one
can always create a "forward" index that actually provides the backward
direction you are looking for.

There may be some dependencies in the various isolation levels that
may also need to be addressed - ie. previous key locking probably needs
different scan implementation in backward vs. forward.

Also harder would be to change the existing interfaces to be able to
go forward and then back, most of my comments apply to just going in
a single direction.  Language can also current ask for prefetch
internal to the scan (it exists between store and language) - so there
may be multiple layers of prefetch going on.

Having said all that, I thought all of the updatable result set stuff
was implemented way above store -- I am definitely not an expert in this
stuff.  Store

Rick Hillegas wrote:
> Hey Mike,
> 
> Can you shed some light on this issue? Can the Store layer walk 
> backwards through an index? Or do you have to reposition by key and then 
> inch forward again?
> 
> Thanks,
> -Rick
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: updatable resultSet
> From:
> "Dag H. Wanvik" <Da...@Sun.COM>
> Date:
> Tue, 11 Oct 2005 18:12:41 +0200
> To:
> Dag.Wanvik@Sun.COM
> 
> To:
> Dag.Wanvik@Sun.COM
> CC:
> Derby Development <de...@db.apache.org>, mikem_app@sbcglobal.net
> 
> 
> Hi,
> 
> I notice the current forward only, updatable implementation does not
> do prefetch from the network client driver, hence removing a need to
> move backwards when perfoming an update in the middle of a prefetch
> set.
> 
> It seems a main problem with implementing scrollable sensitive result
> sets is being able to scan backwards (both heap and btree). Can
> somebody cast some light on what, if any, underlying assumptions would
> make this hard?
> 
> Mike, can you comment on this perhaps?
> 
> Thanks,
> Dag