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" <[EMAIL PROTECTED]>
Date:
Tue, 11 Oct 2005 18:12:41 +0200
To:
[EMAIL PROTECTED]
To:
[EMAIL PROTECTED]
CC:
Derby Development <[email protected]>, [EMAIL PROTECTED]
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
