Hi,

I couldn't find anything on the list archives on this topic, so here goes..

My question is: how can I effectively manage a 'simultaneous user'
resource consumption policy without an explicit client request to
terminate the session?

If I use http basic authentication, I can enforce a login.  Or I can use
source IP to tell who they are...

I can use SRW:authenticationToken to keep track of who is who on each
subsequent request to keep the session live...

But without an explicit request to terminate the session, there appears
to be no other mechanisms than to either
a) after each search request, leave each user logged in until their
session times out, or
b) terminate the session immediately after every search response is sent.

What I'm concerned about is federated client systems that have the
common 2-phase model of  'broadcast discovery' mode to see what servers
have hits, followed by 'target select' where the user opts to browse the
results of a given target with hits.  I can't really rely on timeout
because its typical that these federated clients don't get good hits
from every target they send their query to.  In most cases, the user is
not coming back.

It would be more efficient if these federated clients explicitly
terminated their association with each target after the broadcast search
is done.

It isn't really an issue of resources consumed by open sessions, I could
care less about that.  Its more of a question on how to accomodate the
business model where institutional access to a database is sold on a
simultaneous user basis.  In this model, users are counted as
simultaneous users from the moment they do their first search, until
they explicitly logout, or timeout.

Federated systems are an anomally.  My own opinion is that is would be
unfair (and inefficient) to count the user as a simultaneous user during
the broadcast phase.  It would work better if we didn't count them as a
user until they started browsing results.

One possible way to tell the difference between 'normal' users who are
doing searches and 'federated systems' might be to compare their values
for maximumRecords.  I suspect most clients searching a single target
will have some positive value here and many federated system might have
maximumRecords=0 if they are in the discovery mode.  My server could log
out any user after responding to a maximumRecords=0 request, but
otherwise leave them logged in.

Beside being a kludge, it also means that a single-target user has no
way of explicitly logging out (unless they know the trick of sending a
maximumRecords=0 query!)

Any thoughts on this?

Thanks,
Pete Ciuffetti
KnowledgeSite, Inc.