db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mamta Satoor <msat...@gmail.com>
Subject Re: Paging Mike Matrigali
Date Wed, 12 Oct 2005 18:15:35 GMT
Yes, you are right. The forward only updatable resultset was implemented
over existing store layer.
 Mamta

 On 10/12/05, Mike Matrigali <mikem_app@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" <Dag.Wanvik@Sun.COM>
> > Date:
> > Tue, 11 Oct 2005 18:12:41 +0200
> > To:
> > Dag.Wanvik@Sun.COM
> >
> > To:
> > Dag.Wanvik@Sun.COM
> > CC:
> > Derby Development <derby-dev@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
>
>

Mime
View raw message