Re: [Springframework-developer] Synchronization policy in the Springcode base

[Juergen H. <jue...@in...>]

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