db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <sathe...@Sourcery.Org>
Subject Re: Paging Mike Matrigali
Date Wed, 12 Oct 2005 19:06:15 GMT
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" <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