Re: [Springframework-developer] Synchronization policy in theSpringcode base

[roger h. <apo...@sn...>]

Many thanks Juergen

I'll just post a link back to your response I think, since the reaction of some
spring developers was stated as an issue ;)

Roger


"Juergen Hoeller" <jue...@in...> wrote in message
news:200...@ma......
> As far as I gathered when browing through that thread, the situation isn't
> something to worry about: As pointed out, Spring publishes its singleton
> beans safely. Peter states that this is only guaranteed on JDK 1.5+, but as
> Matthias points out, thread-safe publication via a synchronized Map works
> fine on all mainstream JVMs back until 1.3. If it wouldn't, no Servlet
> container or any other pre-JDK-1.5 container machinery would be able to work
> correctly (as far as I can tell). Remember that this would not only affect
> Spring's container; it would affect any other kind of container that allows
> for multi-threaded access as well.
>
> As for the point that singleton beans should internally care for
> thread-safety of their configuration fields, since they might run outside of
> Spring: I see the point, but I don't think it is really relevant in
> practice. Any such beans using setter injection have to be safely published
> (after creation has finished) by whoever creates them, be it a container or
> custom startup code. And of course the container itself (e.g. a Spring
> ApplicationContext reference) has to be safely published as well (e.g. as
> ServletContext attribute), as pointed out by Matthias). Which is provided by
> all of Spring's out-of-the-box environments and reasonably easy to achieve
> in custom startup code in any kind of environment.
>
> I do appreciate the idea of marking configuration fields with a special
> annotation in order to improve readability, making it clear that they are
> 'final once configured' (to anyone looking at the code), unless they are
> clearly documented as supporting 'hot' changes (e.g. through JMX), in which
> case (and only in this case) access to them would have to be synchronized.
> We should document these basic rules more clearly, despite them being
> general Setter Injection rules, not really Spring-specific rules.
>
> As indicated above, I don't think that there's much point in making
> configuration fields volatile just to allow for use in a non-locked
> environment. After all, publishing bean instances early, in potentially
> half-configured state, is a bad idea in any case, no matter whether the
> fields would be correctly visible during such a phase. A bean instance does
> need to go through its entire creation process (including auto-proxying etc)
> before it may be published; another basic rule that may need more explicit
> documentation.
>
> Unfortunately, I don't have much further time at present, so I probably
> won't participate in that thread directly. Feel free to quote me if you like
> :-)
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of roger holbrook
> Sent: Thursday, February 22, 2007 7:53 PM
> To: spr...@li...
> Subject: [Springframework-developer] Synchronization policy in the
> Springcode base
>
>
> FYI: Rod and Juergen
>
> There's an interesting thread over on the 166-concurrency list:
>
> http://thread.gmane.org/gmane.comp.java.jsr.166-concurrency/3615/focus=3636
>
> This includes a discussion of synchronization policy in the spring code
> base, with contributions from several of the authors of Java Concurrency in
> Practice.
>
> In support of Springs good name, & what sounds like a bunch of would be
> spring advocates, perhaps one of you might like to respond to the above post
> ?
>
> Roger
>
>
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's
> Techsay panel and you'll get the chance to share your opinions on IT &
> business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV