Re: [Koha-zebra] Perl Zoom Persistent Connections

[Thomas D]

I realise that I was asking on the Koha-Zebra list as that is the context
for which the forthcoming Perl Zoom bindings are to be written.  The issue I
was concerned with is the many possible applications of Z39.50 services in
the wild Z39.50 jungle, with the understanding that one still has to be
respectful of server resources.  I was not necessarily referring to
connecting to a safe local Zebra database.

Having a persistent connection is a real advantage in the jungle, and seemed
to be treated differently by the server than one that had been merely
instantiated as a non-persistent connection.  I find nothing in the Z39.50
standard referring to persistent connections but having one had seemed to
reduce the experience of timeouts from the server and allow retrieving
results from the end of a large result set instead of only those from the
beginning of a large result set.

Maybe my experience with persistent connections is merely based relative to
an insufficiently long client side connection timeout setting.  The
advantage of not having to worry about client side timeouts is significant
given the unreliability of server response time and the occasional
legitimate need for large result sets.  Illegitimate large result sets would
come from poorly formed queries that return too many unwanted results. 
Legitimate large result sets would come from precisely formed queries that
still return large numbers of wanted results or large numbers of unavoidable
unwanted results.  Legitimate large result sets could also come from
aggregating several precise queries.

A related issue is support for extended services which could provide another
means for treatment of large result sets if the server supports the
necessary extended services.  Persistent result set might be used for this
purpose.  This may allow a query to be given at time when it is most
convenient for the client user to place a query and for the client to
retrieve the result set later when it may be most convenient for the server
to respond with a large result set.  Unfortunately, I can find no
documentation with detailed examples of how to actually use Z39.50 extended
services.

Does the previous answer about the possible value of persistent connections
change when used in the context of the wild Z39.50 jungle?

What extended services will the forthcoming Perl Zoom bindings support?  Do
you know of any helpful documentation for possible uses of extended
services, such as persistent result set, with clear detailed examples?


Thomas D


Quoting Mike Taylor <address@hidden> :
> ---------------- Beginning of the original message ------------------
> 
> > Date: Fri, 19 Aug 2005 19:44:08 +0200
> > From: Thomas D <address@hidden>
> > 
> > Persistent connections are kept alive continuously and
> should not
> > require reinitialisation of a new connection for each query
> [...]
> 
> No indeed -- nor they do.
> 
> > [...] nor should they time out arbitrarily when the server
> > determines your connection is inactive or becomes 'tired' of
> serving
> > more results.
> 
> Well, that is the server's choice.  You can't _make_ it do
> something
> it doesn't want to do.  However --
> 
> > yaz_connect() parameter options include persistent.
> > [...]
> > "A boolean. If TRUE the connection is persistent; If FALSE
> the
> > connection is not persistent. By default connections are
> persistent."
> 
> -- I see.  This is an application-level hack, then.  The ZOOM
> connection object, if it notices that the underlying Z39.50
> connection
> has gone away, will silently try to re-forge it and then
> continue as
> if nothing had happened.  I'm not sure that "persistent" is a
> good
> name for this: something uglier like "auto_reconnect" would
> have been
> more explicit.
> 
> In any case, I doubt you'll need that in the case of a
> tightly-bound
> system such as a Koha installation that runs its own Zebra
> server.
> You shouldn't run into the kinds of unreliable-server problems
> that
> you can get out there in the wild Internet.
> 
> The simple answer to your question is that if ZOOM-C has the
> auto_reconnect functionality, the ZOOM-Perl will inherit it. 
> If not,
> it won't.  If this is a real requirement, we could look at
> adding it

> to ZOOM-C if it's not already there.
> 
> Hope that helps.
> 
>  _/|_ 
> ___________________________________________________________________
> /o ) \/  Mike Taylor  <address@hidden> 
> http://www.miketaylor.org.uk
> )_v__/\  "What is this talk of 'release'?  Klingons do not
> make software
>        'releases'.  Our software 'escapes,' leaving a bloody trail
> of
>        designers and quality assurance people in its wake." --
> Klingon
>        Programming Mantra
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference &
> EXPO
> September 19-22, 2005 * San Francisco, CA * Development
> Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *
> Testing & QA
> Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Koha-zebra mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/koha-zebra
> 
> ------------------- End of the original message ---------------------




---------------------------------------------
Protect your mails from viruses thanks to Alinto Premium services 
http://www.alinto.com