Given that there is a violation, and the proposed solution is simpler, would you take it in the next release?
Thanks, Ohad On Sun, Sep 26, 2010 at 10:42 PM, Tim Whittington <t...@apache.org> wrote: > 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 > >
