You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Niall Gallagher <ni...@analog.com> on 2004/01/15 14:38:07 UTC
Synchronizing a Context
Hi,
I am relatively new to Velocity and I have been trying to write a shared
Context for a group of Servlets. However, I see in the Javadoc
documentation that the VelocityContext object is not thread safe, I have
also examined the hierarchy of super classes and find that it pretty
much comes down to the InternalContextBase.icachePut and
InternalContextBase.icacheGet methods.
What I was wondering was, if I synchronized these methods in a subclass
and extended the AbstractContext would I have a thread safe Context
implementation ? If not is there any support within the core Velocity
API for thread safe (preferably chained) Context objects. Any help on
this would be appreciated!
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Synchronizing a Context
Posted by Niall Gallagher <ni...@analog.com>.
As far as I know the context is used to cache some things relating to
the AST, these need to be synchronized in case the same context is
passed into the Velocity runtime or different templates.
Niall
Cesare Rocchi wrote:
> Geir Magnusson Jr wrote:
>
>>
>> On Jan 15, 2004, at 8:38 AM, Niall Gallagher wrote:
>>
>>> Hi,
>>>
>>> I am relatively new to Velocity and I have been trying to write a
>>> shared Context for a group of Servlets. However, I see in the
>>> Javadoc documentation that the VelocityContext object is not thread
>>> safe, I have also examined the hierarchy of super classes and find
>>> that it pretty much comes down to the InternalContextBase.icachePut
>>> and InternalContextBase.icacheGet methods.
>>
>
> Perhaps I didn't catch the point ... but ...
> what if you synchronize the methods accessing your context object?
>
> HTH
>
> -c.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Synchronizing a Context
Posted by Ch...@dlr.de.
Why synchronize if the most common operation in a context is reading?
Therefore, as Geir already stated, use a chained context. Even though
you don't explicetely #set(...) values in your context, a #foreach(...)
and #macro calls will write/put to your context. A chained context
decouples the context for the template from any common part setup
beforehand behind scenes.
Alternatively consider using the ServletContext to keep session or servlet
globals - this is for free in a servlet environment without having
to do a line of code or config in VVS or VelocityServlet. Example:
#macro( call $tmp )#if($tmp)#**##end
...
#call( $request.session.setAttribute('foo',"bar") )
...
#if( $request.session.getAttribute('foo') )
Variable 'foo' is now $request.session.getAttribute('foo')
#else
Variable 'foo' not defined in session.
#end
(use $req or $request depending on how your servlet is setup.)
See the related thread on this issue in the archive: "Global Variable in vm files"
Also be sure the context objects and tools are also thread safe.
Hope this helped,
Christoph
Cesare Rocchi wrote:
> Niall Gallagher wrote:
>
>> Exactly, so if I did somthing like
>> servletContext.setAttribute("sharedContext", mySharedContext) and
>> multiple independant servlets required access to the context to render
>> a template, then there would be a problem with the AST caching and
>> also setting and getting from the context...at least this is what I
>> have understood of the AbstractContext.
>
>
> ... but if the context has just a 'get' method and doesn't change along
> the processing fine ... but if you have a getter and a setter both have
> to be synchronized, otherwise a getter could read the context while a
> setter is updating it, isn't it?
>
> -c.
--
:) Christoph Reck
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Synchronizing a Context
Posted by Niall Gallagher <ni...@analog.com>.
>> Exactly, so if I did somthing like
>> servletContext.setAttribute("sharedContext", mySharedContext) and
>> multiple independant servlets required access to the context to
>> render a template, then there would be a problem with the AST caching
>> and also setting and getting from the context...at least this is what
>> I have understood of the AbstractContext.
>
>
> ... but if the context has just a 'get' method and doesn't change
> along the processing fine ... but if you have a getter and a setter
> both have to be synchronized, otherwise a getter could read the
> context while a setter is updating it, isn't it?
I concerns are slightly different...synchronization of the Context.get
and Context.put were not problems..I could simply synchronize all the
methods of the Context interface and use it to set and get
properties....However what if this happened....what would happen with
the unsynchronized icachePut and icacheGet methods ?
servlet in thread 1
template1.merge(out2, mySharedContext);
servlet in thread 2
temjplate2.merge(out2, mySharedContext);
I think you are making a point for a context being a container of
properties (perhaps wrapped within a local VelocityContext), in this
case simply retrieving data without synchronization is fine..my only
worries, which I am far too lazy to explore, are the Velocity internals,
I dont know what the AST is caching nor do I want to know. In terms of
the simple context usage I would simply have cut and pasted
VelocityContext into a file and replaced the HashMap used with a
Hashtable....apparently this will not work.....in any case I have
decided that extending the AbstractContext is not a good idea for
me...it was not intended for use in this environment....Instead I have
just implemented the Context methods around a Hashtable...... which is
similar to what you have suggested ;)
Thanks,
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Synchronizing a Context
Posted by Cesare Rocchi <ro...@itc.it>.
Niall Gallagher wrote:
> Exactly, so if I did somthing like
> servletContext.setAttribute("sharedContext", mySharedContext) and
> multiple independant servlets required access to the context to render a
> template, then there would be a problem with the AST caching and also
> setting and getting from the context...at least this is what I have
> understood of the AbstractContext.
... but if the context has just a 'get' method and doesn't change along
the processing fine ... but if you have a getter and a setter both have
to be synchronized, otherwise a getter could read the context while a
setter is updating it, isn't it?
-c.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
+---------------------------------------+
Cesare Rocchi
ITC-IRST Povo I-38050 (TRENTO) ITALY
http://tcc.itc.it/people/rocchi.html
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Synchronizing a Context
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 20, 2004, at 8:19 AM, Niall Gallagher wrote:
>> I am relatively new to Velocity and I have been trying to write a
>> shared Context for a group of Servlets. However, I see in the Javadoc
>> documentation that the VelocityContext object is not thread safe, I
>> have also examined the hierarchy of super classes and find that it
>> pretty much comes down to the InternalContextBase.icachePut and
>> InternalContextBase.icacheGet methods.
>
>>>
>>> Perhaps I didn't catch the point ... but ...
>>> what if you synchronize the methods accessing your context object?
>>
>>
>> That might work, but that would be solving a slightly different
>> problem, right? aren't you trying to share some of your application
>> data between servlets?
>>
>> geir
>>
> Exactly, so if I did somthing like
> servletContext.setAttribute("sharedContext", mySharedContext) and
> multiple independant servlets required access to the context to render
> a template, then there would be a problem with the AST caching and
> also setting and getting from the context...at least this is what I
> have understood of the AbstractContext.
Yes, but you could wrap that context in each use :
VelocityContext vc = new
VelocityContext(servletContext.getAttribute("sharedContext")) // or
whatever
and that would probably be ok
geir
>
> Niall
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Synchronizing a Context
Posted by Niall Gallagher <ni...@analog.com>.
> I am relatively new to Velocity and I have been trying to write a
> shared Context for a group of Servlets. However, I see in the Javadoc
> documentation that the VelocityContext object is not thread safe, I
> have also examined the hierarchy of super classes and find that it
> pretty much comes down to the InternalContextBase.icachePut and
> InternalContextBase.icacheGet methods.
>>
>> Perhaps I didn't catch the point ... but ...
>> what if you synchronize the methods accessing your context object?
>
>
> That might work, but that would be solving a slightly different
> problem, right? aren't you trying to share some of your application
> data between servlets?
>
> geir
>
Exactly, so if I did somthing like
servletContext.setAttribute("sharedContext", mySharedContext) and
multiple independant servlets required access to the context to render a
template, then there would be a problem with the AST caching and also
setting and getting from the context...at least this is what I have
understood of the AbstractContext.
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Synchronizing a Context
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 19, 2004, at 6:54 AM, Cesare Rocchi wrote:
> Geir Magnusson Jr wrote:
>> On Jan 15, 2004, at 8:38 AM, Niall Gallagher wrote:
>>> Hi,
>>>
>>> I am relatively new to Velocity and I have been trying to write a
>>> shared Context for a group of Servlets. However, I see in the
>>> Javadoc documentation that the VelocityContext object is not thread
>>> safe, I have also examined the hierarchy of super classes and find
>>> that it pretty much comes down to the InternalContextBase.icachePut
>>> and InternalContextBase.icacheGet methods.
>
> Perhaps I didn't catch the point ... but ...
> what if you synchronize the methods accessing your context object?
That might work, but that would be solving a slightly different
problem, right? aren't you trying to share some of your application
data between servlets?
geir
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Synchronizing a Context
Posted by Cesare Rocchi <ro...@itc.it>.
Geir Magnusson Jr wrote:
>
> On Jan 15, 2004, at 8:38 AM, Niall Gallagher wrote:
>
>> Hi,
>>
>> I am relatively new to Velocity and I have been trying to write a
>> shared Context for a group of Servlets. However, I see in the Javadoc
>> documentation that the VelocityContext object is not thread safe, I
>> have also examined the hierarchy of super classes and find that it
>> pretty much comes down to the InternalContextBase.icachePut and
>> InternalContextBase.icacheGet methods.
Perhaps I didn't catch the point ... but ...
what if you synchronize the methods accessing your context object?
HTH
-c.
--
+---------------------------------------+
Cesare Rocchi
ITC-IRST Povo I-38050 (TRENTO) ITALY
http://tcc.itc.it/people/rocchi.html
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Synchronizing a Context
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 15, 2004, at 8:38 AM, Niall Gallagher wrote:
> Hi,
>
> I am relatively new to Velocity and I have been trying to write a
> shared Context for a group of Servlets. However, I see in the Javadoc
> documentation that the VelocityContext object is not thread safe, I
> have also examined the hierarchy of super classes and find that it
> pretty much comes down to the InternalContextBase.icachePut and
> InternalContextBase.icacheGet methods.
yes, but see below
>
> What I was wondering was, if I synchronized these methods in a
> subclass and extended the AbstractContext would I have a thread safe
> Context implementation ? If not is there any support within the core
> Velocity API for thread safe (preferably chained) Context objects. Any
> help on this would be appreciated!
You should be able to do it by chaining - because if I understand what
you want, you want to share data between threads. I think that will
work - I'll have to go stare at things again, but I'd look into that
first before doing anything fancy.
geir
>
> Niall
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org