"Geir Magnusson Jr." <[EMAIL PROTECTED]> writes:

> Daniel Rall wrote:
> > 
> > "Geir Magnusson Jr." <[EMAIL PROTECTED]> writes:
> > 
> > > Note also that you get your own ArrayList when you #set() or just pass
> > > one to a method, so there should be no fear of inter-thread problems.
> > > Muck with it to your hearts content.
> > 
> > But remember that ArrayList itself is not synchronized!  :)
> 
> I don't understand why this matters, so if I am missing something,
> please, lets get this straightened out.
> 
> When I said above that one should have no fear of inter-thread problems,
> I meant that when you have a template that has 
> 
>   #set( $foo = ["a","b","c"] )
> 
> each thread (say a request to a servlet) merging that template will get
> a new ArrayList placed in that thread's context.  Therefore, each thread
> of execution can do what it wishes with that ArrayList w/o fear of
> affecting any other thread. (I think... :\ )
> 
> Since 'the rule' is that the context must not be used/shared
> simultaneously across threads, it doesn't matter that ArrayList isn't
> synchronized. ( Aside from being a horrible idea anyway, one of the
> reasons for 'the rule' is that the VelocityContext default context
> implementation uses a HashMap, which isn't synchronized :)

Java objects already in the context have the possibility of themselves
being multithreaded.  I'm not by any means recommending this, I'm just
saying that it's possible.  Use of an ArrayList in such a situation
would lead to Big Trouble.  However, one should avoid such a design in
the first place...I just wanted to post a reminder.
-- 

Daniel Rall <[EMAIL PROTECTED]>

Reply via email to