On 4/7/06, David P <[EMAIL PROTECTED]> wrote: > > > --- Nathan Bubna <[EMAIL PROTECTED]> wrote: > > > In a web application, thread-safety is only a > > concern if your context > > objects are used in the session or application > > scopes. > > I'm using VelocityServlet,
just in case you didn't know, the VelocityServlet has been deprecated in favor of the VelocityViewServlet in the VelocityTools subproject. > which provides a context > object when its handleRequest() method is invoked. I > use Context::put() to add containers to the data model > used by the template. Some containers are static in > order to maintain state. > > I don't see a way to indicate scope via put(). in your case, scope isn't something you indicate; it is something you do. anything static is implicitly application scope because it is shared by all instances and therefore all threads. anything created for a servlet request is request scope. to have something be session scoped, you must put it in the HttpSession. > > Each servlet request is just one thread in a normal > > web application. So for each request, you > > should probably be creating a new VelocityContext > > and new/different instances of any mutable classes > > into that context. This is the standard practice > > for any view technology > > (JSP/Velocity/Freemarker/etc). > > I suppose I could make a copy of every static > container before putting that copy into the context, > but it seems pretty wasteful. if the container is static, i'm not sure i understand what the point of copying it is. > It would also preclude putting any singletons into the context. it precludes putting any *mutable* singletons in the context, and that's a good thing! i don't think mutable singletons are ever a good idea, especially in a threaded application like a webapp. they have big thread-safety issues. this will be true whether you use ASP, JSP, Velocity, or any other view technology. immutable singletons, on the other hand, are always thread safe in any application. some people still don't like them, but they won't have thread-safety issues. > > On 4/7/06, David P <[EMAIL PROTECTED]> wrote: > > > Some archive msgs like this one point out that > > > VelocityContext is not thread-safe: > > > > > > > > > http://servlets.com/archive/servlet/ReadMsg?msgId=148259&listName=velocity-user > > > > > > I have put some objects in my context that could > > be > > > modified by other threads. I can make these > > accesses > > > thread-safe when using #set and #if, but I can't > > think > > > of a way to protect containers when used by #for. > > For > > > example, another thread might remove an element > > from a > > > container in the context while #for is iterating > > over > > > it. Synchronizing the iterator method of the > > container > > > wouldn't provide any protection. And putting a big > > > synchronize block inside every servlet in the app, > > > blocking on a shared object, wouldn't work because > > > there's no way to get the Velocity template to > > wait on > > > the same lock...right? > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Tired of spam? Yahoo! Mail has the best spam > > protection around > > > http://mail.yahoo.com > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
