Re: LookupCache, ServiceDiscoveryListener and discard guarantees

Gregg Wonderly wrote:
> Rick Moynihan wrote:
>> Are any assurances made by LookupCache that calls to discard()
>> will result in serviceRemoved() method invocations prior to any calls to
>> serviceAdded()/serviceChanged() involving the discarded service?
>
> Technically, it's impossible for the appropriate orderings to be
> guarenteed,
> because your view of the "lost" service is in no way tied to the LUS's
> view of a
>  "discovered" service.  What happens when there is a "race condition"
> such as
> this, is that the service registration will be missing for some period
> of time.
>
> I don't use the lookup cache in my Jini applications.  Instead, I've
> implemented
> by own in which I always initiate a lookup, after a discard by dropping the
> listeners to the affected Registrars, and then adding them back, and
> performing
> a lookup.
>
> This allows me to always have a "concrete" view of the state of the system,
> driven by the view that I desire to have.  I also then periodically
> requery the
> LUS with the same lookup parameters to keep from getting bit by odd
> timing or
> interesting failure modes that are really not solvable in 100% of the
> cases.

Hi Gregg,

Given all the stuff LookupCache takes care off and the amount of time
that goes in building "state maintaining utilities while getting input
from a thousand places". I really try to understand why one wants to
build something similar although different, has it something to do with
the reliance on remote events or your particular lookup service API?
--
Mark

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]