search

javaee / ejb-spec

See javax.ejb project for API. Contains legacy issues only.
https://github.com/javaee/javax.ejb
6 stars 1 forks source link

clarify ThreadLocal usage in ejb environment #123

Open glassfishrobot opened 10 years ago

glassfishrobot commented 10 years ago

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?

glassfishrobot commented 10 years ago

Reported by ymajoros

glassfishrobot commented 9 years ago

ymajoros said: Can anyone comment on this, please?

glassfishrobot commented 9 years ago

wolfc said: Why would you want to use ThreadLocal? What are you trying to achieve with it?

glassfishrobot commented 9 years ago

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?

glassfishrobot commented 9 years ago

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.

glassfishrobot commented 9 years ago

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?

glassfishrobot commented 9 years ago

ymajoros said: Hello,

Could anyone comment on this one?

Thanks

glassfishrobot commented 9 years ago

wolfc said: The scope of unspecified things is limitless, hence it'll never be documented.

glassfishrobot commented 9 years ago

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.

glassfishrobot commented 9 years ago

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.

glassfishrobot commented 9 years ago

@ldemichiel said: Cautionary note should be added to EJB spec

glassfishrobot commented 7 years ago

This issue was imported from java.net JIRA EJB_SPEC-123