Are custom tags thread-safe?

[Big Slim]

Okay, I'm sure this has been asked here before, but here goes. I have a
custom tag with one instance variable, a String named "page."

A couple of JSPs use this same tag, but depending on which page uses
it, the "page" variable may be different. In the doEnd() method, the
tag tests the value of the "page" variable and does different things
depending on which page calls it.

Is this custom tag thread-safe? It would appear that it is not, since
any thread could come along and change the value of "page" at any time.
A Java programmer I know said it is okay as long as I let the tag "fall
out of scope."

I'm not sure what he meant by that. I am not saving the tag in any
scope, so I assume he means this instance of the tag will be garbage
collected after the request has been processed (similar to an object
created with the "new" constructor).

However, I'm in doubt. Isn't only one instance of a custom tag created
for all threads to access?

Help!--Big Slim

 

[abigale_carson]

Hi Mr. Slim,

this was asked many moons ago in another forum--might be useful, might
be junk. Here's the link, nonetheless:

http://groups.google.com/group/webl...custom+tags+jsp&rnum=2&hl=en#421d9e3e61f90655

or, if'n that broke, here it is again:

http://linkfrog.net/dabl

Bye, Abigale

 

[isamura]

: Okay, I'm sure this has been asked here before, but here goes. I have a
: custom tag with one instance variable, a String named "page."
:
: A couple of JSPs use this same tag, but depending on which page uses
: it, the "page" variable may be different. In the doEnd() method, the
: tag tests the value of the "page" variable and does different things
: depending on which page calls it.
:
: Is this custom tag thread-safe? It would appear that it is not, since
: any thread could come along and change the value of "page" at any time.
: A Java programmer I know said it is okay as long as I let the tag "fall
: out of scope."
:
: I'm not sure what he meant by that. I am not saving the tag in any
: scope, so I assume he means this instance of the tag will be garbage
: collected after the request has been processed (similar to an object
: created with the "new" constructor).
:
: However, I'm in doubt. Isn't only one instance of a custom tag created
: for all threads to access?
:
I don't think so. If that was the case all tags would be non thread-safe. Tag instances are created
and gc'ed once the response is generated.

..k

 

[Thomas Hawtin]

Okay, I'm sure this has been asked here before, but here goes. I have a
custom tag with one instance variable, a String named "page."

A couple of JSPs use this same tag, but depending on which page uses
it, the "page" variable may be different. In the doEnd() method, the
tag tests the value of the "page" variable and does different things
depending on which page calls it.

Is this custom tag thread-safe? It would appear that it is not, since
any thread could come along and change the value of "page" at any time.
A Java programmer I know said it is okay as long as I let the tag "fall
out of scope."

I'm not sure what he meant by that. I am not saving the tag in any
scope, so I assume he means this instance of the tag will be garbage
collected after the request has been processed (similar to an object
created with the "new" constructor).

However, I'm in doubt. Isn't only one instance of a custom tag created
for all threads to access?

No, tags work in a different way to Servlets. A tag object is only in
use at one point by one request at a time. That allows properties to be
set on the instance and state to be kept.

Depending on the JSP implementation, the tag object may or may not be
reused. If it is reused, it will never be in simultaneous use and is not
responsible for synchronisation. Most tag creation is little more than
memory allocation, and therefore pooling is of dubious benefit. The
reuse of tags is not done through weak reference or other uses of the
garbage collector, so the JSP implementation has no reasonable way of
detecting abuses. IIRC, the JavaDocs have some basic state diagrams.

Because a tag can be reused, you should not keep any references to it
outside of its scope. This is roughly analogous to storing request state
in a servlet instance variables. I have seen programmers attempting to
"reuse" the tag class. It doesn't work, and isn't very good style
anyway. The only clients of a tag should be the JSP page and other tags
through ancestry. If you need to keep any state beyond the tag, copy it
into a new class.

Obviously, the use of static variables is generally thread-hostile, and
should be avoided.

Tom Hawtin

 

[John C. Bollinger]

[Concerns about thread safety with custom tags]

No, tags work in a different way to Servlets. A tag object is only in
use at one point by one request at a time. That allows properties to be
set on the instance and state to be kept.

Depending on the JSP implementation, the tag object may or may not be
reused. If it is reused, it will never be in simultaneous use and is not
responsible for synchronisation. Most tag creation is little more than
memory allocation, and therefore pooling is of dubious benefit. The
reuse of tags is not done through weak reference or other uses of the
garbage collector, so the JSP implementation has no reasonable way of
detecting abuses. IIRC, the JavaDocs have some basic state diagrams.

[more good advice elided]

Because of potential reuse of tag handler instances, you should also be
sure to adhere to the rules for tag handler behavior that you will find
in the JSP specs. Among the more important is that after a tag
handler's instantiation and until its release(), tag handler properties
that are exposed as tag attributes may only be changed via their
assigned setter methods, and those methods may only be invoked by the
JSP page implementation. This ties in with Tom's points about handlers
retaining state.

Relative to thread safety, however, Tom already covered the main point,
which is that the servlet spec promises that a tag handler is assigned
exclusively to servicing one request (in one thread) at a time.