Well, actually this is more of a lifecycle question.
Specifically, if the object is being serialized, will the @Resource injections happen when the object is reloaded? If that's the case, then why serialize those resources out at all?
Now, if, for some reason, a program serializes the object itself, then there's no lifecycle at all and, in fact, the programs can't ask the container to "reinject" its resource on a newly marshaled instance. So, in that case, you DON'T want those fields to be volatile as there is basically "no way" for them to be recovered.
In practice, the @Resource annotation is only on classes managed (or at least should be managed) solely by the container, so they should be lifecycle aware, and have no need to be serialized as they'll be reinjected.
Since many of the @Resources ARE simply interfaces, and those interfaces don't extend Serializable, there is no guarantee that any of the artifacts represented by those interfaces are serializable, so it is prudent to mark them as volatile.
What is interesting, tho, is simply that it is not a REQUIREMENT that @Resource annotated properties are marked volatile. That means it is either an oversight of the spec authors, or that if you have classes where @Resource annotated properties are NOT marked volatile, then that class is still a portable artifact in the JEE sense.
If it's the former, then marking it volatile is good practice to work around a hole in the specification. If it's the latter, then it's obviously not necessary at all.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=245852