This is technically a race condition, but given the vague information provided in ServletContextAttributeEvent (e.g. the inability to differentiate adds vs replaces) I can't see it causing a real problem. i.e. there's no atomicity in the interaction of an attribute listener with the context, so a temporary internal inconsistency isn't going to hurt.
> val = attributes.put(name, value); > if (val != null) > replaced = true; +1 - this is simpler in any case. cheers tim On Mon, Sep 27, 2010 at 6:25 AM, Ian Darwin <i...@darwinsys.com> wrote: >> In this case, both threads will >> continue running the function with ?replaced? bit turned on and the oldValue >> of both thread will point to the same location. This means that the value of >> the first thread that did the put operation will not be treated as a value >> that was replaced. >> >> Could you please let me know whether you consider this as a bug? > > Is it any different than if two threads invoke the operation serially? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
