• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Custom tag multithreading

 
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Peter - that has cleared it up
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Peter den Haan
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic