Open glassfishrobot opened 10 years ago
Reported by ymajoros
ymajoros said: Can anyone comment on this, please?
wolfc said: Why would you want to use ThreadLocal? What are you trying to achieve with it?
ymajoros said: Nothing. I'm constantly trying to convince some colleagues not to use it. Do you think I am right saying the specification prohibits that? Should it be explicitely written in the specs?
wolfc said: Right now the spec leaves it unspecified, as it should be.
I reckon for almost every scenario there is a viable solution that does not include the usage of ThreadLocal.
In future it might become something specified, but that can turn either way. If your colleagues reckon that is an acceptable risk to the project, then so be it.
ymajoros said: So, you're basically saying it's not portable, right? If so, shouldn't this be mentioned in the specification to avoid endless debate on its recurrent usage?
ymajoros said: Hello,
Could anyone comment on this one?
Thanks
wolfc said: The scope of unspecified things is limitless, hence it'll never be documented.
ymajoros said: Thanks for your comment.
I still think there is room for improvement, like an additional paragraph: "The enterprise bean should make no assumption on the threading model, and thus should not associate any information with a thread".
I understand this doesn't cover the all unspecified cases. This is just a clarification to avoid some pain.
arnauldvm said: I second the proposal of ymajoros. The current ambiguity of the spec on this subject is the source of endless discussions (at best), and of dangerous practices by coders in many cases.
@ldemichiel said: Cautionary note should be added to EJB spec
This issue was imported from java.net JIRA EJB_SPEC-123
My interpretation from EJB3.2/§16.2.2 is that you can't have ThreadLocal's, the main reason being that thread management is not portable across server implementations. As we know, there are no guarantees on threads, so it's not reliable at best, and probably dangerous.
From this, ThreadLocal usage can't be portable. Introduction of §16.2.2 says this:
"This section describes the programming restrictions that a Bean Provider must follow to ensure that the enterprise bean is portable and can be deployed in any compliant EJB container. The restrictions apply to the implementation of the business methods. Section 16.3, which describes the container's view of these restrictions, defines the programming environment that all EJB containers must provide."
So, shouldn't there be some specific paragraph on ThreadLocal, or a more generic which would cite ThreadLocal usage as an example?