> Injection code is evil in some ways; one can't easily
> use 'final' for example to both guarantee and
> document immutability; it's a guessing game.
But final only guarantees the reference is immutable, not the underlying object.
> In the absence of specific guarantees, fields should
> be marked 'volatile'. It has nothing to do with the
> container per se, only with the "happens before"
> clause upon which the JVM memory model rests.
Well, that's the rub. In EJB, there are specific guarantees. That's why, as developers, we don't have to worry about these details.
> To safely not mark a variable 'volatile', the
> following conditions must hold:
> - the variable must be set once and only once
> (barring other synchronization efforts);
> - injecting the variable must "happen before" (JVM
> memory model term) the variable is read by the
> consuming thread.
>
> If the variable is changed more than once, then the
> same "happens before" guarantee must be in place.
> There are many things that guarantee this:
> 'synchronized' on a shared lock, certain operations
> on threads, reads of a shared 'volatile' variable,
> etc.
I can see an EJB container enforcing all of these criteria for us.
> Behavior might be poorly or inaccurately documented,
> and threading is hard to get right, even by
> experienced developers. With those risks in mind,
> using 'volatile' is highly prudent if there is any
> doubt as to the way in which the variable is injected
> and/or how many threads might access it. Use of
> 'volatile' is highly efficient, and injected
> variables probably are not used in tight loops
> anyway. Better safe than sporadically sorry.
But, that's one of the value adds of using the container in the first place, the behavior is well documented, and the threading is delegated to "Them Who Know Best". We're relying upon the container authors to be thread savvy and "do the right things" in the "right places" so that we developers, as consumers of container services, are not burdened with this kind of minutiae.
While the modern annotation scheme in theory allow us to use code outside of the containers, as developers we're assured by the container designers that our code is not running is the wild wild west, but rather in safe compounds and a whole bunch of red tape to keep things in check. While in truth it's fairly easy to run roughshod over the container contracts (most implement the standards but don't actually prevent us doing bad things), most of the time developers simply don't, and it's well known that should they try, they may well find themselves burned beyond recognition in many assorted scenarios.
I'm not saying your advice is bad, but one of the points of using these large software constructs is to make it easier for the Journeyman coders out there to do their jobs and I'd hate to see someone read this and get all panicy about doing the wrong thing, or fretting about taking precautions that, frankly, they don't need to do in this environment.
Always good to understand the plumbing though.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=245878