Date:         Fri, 19 Jul 2002 13:32:50 +0100
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Mike Taylor <[log in to unmask]>
Subject:      Re: queries and result sets
Comments: To: [log in to unmask]
In-Reply-To:  <[log in to unmask]> (message from Ray Denenberg on Thu,
              18 Jul 2002 13:51:15 -0400)

> Date: Thu, 18 Jul 2002 13:51:15 -0400
> From: Ray Denenberg <[log in to unmask]>
>
> Suppose I send a query "title = frogs" and in the
> response there's result set id RS, with idle time
> 10 minutes.
>
> Then I send another query, let's say  it's the
> same, "title = frogs", and I get back the same
> result set name, RS, perhaps with idle time 15
> minutes.
>
> I don't think we nailed this down at the meeting.
> Is this a new result set, though with the same
> name, perhaps because the server only supports one
> result set?
>
> Or is it the same result set, with a renewed idle
> time?

It certainly can't be the latter: the server is not at liberty to
assume that because I submitted the same query, it can use the same
result set -- there may be new records (remember the example of using
SRW to get a periodically refreshed list of the more recent stories to
arrive in the DB from a newswire service.)

So the question resolves to this: if the server has previously issued
a result-set, is it allowed later on to re-issue another result-set
with the same name (irrespective of whether its in response to the
same query or a different one)?

It's tempting to accept Rob's answer:

        If this is before the idle time out of the original result
        set, this is maybe misbehaving as it probably shouldn't reuse
        the resultset while the previous one is /possibly/ still
        around.

        If this is after the idle time out, then it's okay.

But I don't think that's a useful thing to say given how vague the
TTLs are.  We've said all along that they're just a hint and clients
can't rely on them.  What you'd end up with is client code that, if it
gets back another result-set with the same name as one it's already
got, knows then that the old one has disappeared.  That's bad for a
complicated reason that makes perfect sense in my head, but is hard to
explain.

OK, here's an attempt to explain it.  Given that TTLs are unreliable,
what's the usual way for a client to tell whether one of its result
sets is still alive?  It just goes ahead and fetches a record from it,
and sees whether or not it fails with a "Result Set Not Known At This
Address" error.  But that test doesn't work if the server may have
issued another result set with the same name in the mean time: the
client will happily get back a record, but it be the wrong one!

Imagine this scenario.  My application makes an SRW connection and
uses it for two purposes: one module of my code does Zthes-like
searches to find useful terms, and the other searches against (say) a
biblio DB using the terms discovered by the thesaurus.  Now the
searches go like this:

thesaurus module: find "fish", give me the "brief" record.
      SRW server: ok, result-set is called "x"
   biblio module: (checks the "fish" record and discovers a nice
                   narrower term that it's interested in)
                  find "halibut"
      SRW server: ok, result-set is called "x"
                  (Uh-oh!  It re-used the result-set name!)
thesaurus module: give me that thesuaurs record again, but as a "full"
                  record this time.
      SRW server: Sure!  Here's a record from result-set "x"

All very complicated and scary and close to impossible to debug.  I
think the only sensible thing to say is that servers may not re-use
result-set names, period.

 _/|_    _______________________________________________________________
/o ) \/  Mike Taylor   <[log in to unmask]>   www.miketaylor.org.uk
)_v__/\  "In the forwards debate: Rush _is_ past it, despite the odd
         hat-trick" -- Lee Curran.