File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Servlets and the fly likes Custom tag multithreading Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Custom tag multithreading" Watch "Custom tag multithreading" New topic
Author

Custom tag multithreading

Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Hi all,

I had always assumed that a new instance of a Tag in was instantiated to service a request. I just found out the hard way that this is not the case (I assumed that all member variable objects were null on calling the tag - they aren't! they are left at whatever the previous thread set them to)

If a new instance is not created for each request, it follows that tags are not threadsafe either. In this case, is there any way to force the container to create multiple instances of the tags (as a javax.servlet.SingleThreadModel interface does for servlets)? Or do I need to rely on synchronizing?

Any insight greatly apreciated,

Cheers,

Jon


SCJD, SCEA
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Tags are not multithreaded, and don't need to be threadsafe, but neither can you assume that a new tag will be created for every request. The container may use tag pooling whereby a tag, once used, is retired into the pool to be re-used by a different request. The Tag javadoc outlines the lifecycle in detail. See also the release() method. In short, you should reset tag state in doEndTag() and release().

- Peter
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Thanks Peter - that has cleared it up
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61103
    
  66

Actually you can get yourself into trouble resetting a tag.

The container is allowed to assume that it and it alone owns the values of the attributes. So let's say that in one instance of the tag you use xyz="213". If in the next instance you also use the same attribute with the same value, the container is not required to call the setter again. If you have reset the backing variable for the attribute, it will be as if the tag is ignoring the value.

Each container can act differently and still be spec-compliant. So you might get away with something in one, and run into a nightmare if porting to another. Resin, for example, is highly aggressive about optimizing its tag management (one of the reasons that it's so freakin' fast) and won't let you get away with some sloppiness that just may work fine in Tomcat. (Does this sound like I have the scars to prove it, or not?)

So tread lightly. Your best bet is to assume that the container owns the attributes and the instance variables that back them up, and keep hands off!

Internal instance variables not exposed to the container are yours to do with as you wish.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
You're absolutely correct. I once was caught out by an Orion version that patently didn't reset tag attributes, and assumed the spec didn't require the container to do this.

Thanks

- Peter
Jon Entwistle
Ranch Hand

Joined: Feb 20, 2003
Posts: 118
Obviously my mental model of what was going on was way off the mark - a good lesson learnt. Thanks to both of you for setting me straight.

Jon
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Custom tag multithreading