VelocityPage::doPostBuild starts the process. (in turbine-2)
john mcnally
Costas Stergiou wrote:
>
> Please, any final ideas on this issue?
>
> > Actually I am not sure there is a problem (I am just asking
> > and trying to locate the malfunction I came upon).
> >
> > The one question I still don't know the answer:
> > Where the tool is returned back to the pool?
> >
> >
> >
> > ----- Original Message -----
> > From: "John McNally" <[EMAIL PROTECTED]>
> > To: "Turbine Users List" <[EMAIL PROTECTED]>
> > Sent: Wednesday, November 28, 2001 6:32 PM
> > Subject: Re: TurbinePullService + UIManager synchornization problem (Maybe
> > BUG) ?
> >
> >
> > > Once the object is given to a particular request from the pool, that
> > > object will not be given out again until it is returned. Where exactly
> > > do you see the problem? I don't see how you can tell that there is a
> > > problem with the pool code from the code given below.
> > >
> > > john mcnally
> > >
> > >
> > > Costas Stergiou wrote:
> > > >
> > > > iif you look at the code that populates the context with the request
> > > > scope tools, it just pools an object from the Pool (doesn't create
> > > > a new one each time). So, the same instance can be used for more than
> > > > one http requests.
> > > >
> > > > Here is the code from the TurbinePullService.java:
> > > >
> > > > /**
> > > > * Populate the given context with the request-scope tools
> > > > *
> > > > * @param context a Velocity Context to populate
> > > > * @param data a RunData instance
> > > > */
> > > > private void populateWithRequestTools(Context context, RunData
> data)
> > > > {
> > > > // Get the PoolService to fetch object instances from
> > > > PoolService pool = (PoolService)
> > > >
> > > > TurbineServices.getInstance().getService(PoolService.SERVICE_NAME);
> > > >
> > > > // Iterate the tools
> > > > Iterator it = requestTools.iterator();
> > > > while (it.hasNext())
> > > > {
> > > > ToolData toolData = (ToolData)it.next();
> > > > try
> > > > {
> > > > Object tool = pool.getInstance(toolData.toolClass);
> > > > if (tool instanceof ApplicationTool)
> > > > {
> > > > // request tools are init'd with a RunData object
> > > > ((ApplicationTool)tool).init(data);
> > > > }
> > > > // put the tool in the context
> > > > context.put(toolData.toolName, tool);
> > > > }
> > > > catch (Exception e)
> > > > {
> > > > Log.error(
> > > > "Could not instantiate tool " +
> > > > toolData.toolClassName
> > > > + " to add to the context",e);
> > > > }
> > > > }
> > > > }
> > > >
> > > > The only think that it does is that it init's the tool (with the
> > appropriate
> > > > rundata) before
> > > > adding it to the context. But actually it can be the same object
> > instance
> > > > that someone else
> > > > is using at the same moment!
> > > >
> > > > Is that so?
> > > > That's what I understand from the code above,
> > > > Please, correct me if I am wrong.
> > > > Thanks,
> > > > Costas
> > > >
> > > > ----- Original Message -----
> > > > From: "Eric Dobbs" <[EMAIL PROTECTED]>
> > > > To: "Turbine Users List" <[EMAIL PROTECTED]>
> > > > Sent: Wednesday, November 28, 2001 5:51 PM
> > > > Subject: Re: TurbinePullService + UIManager synchornization problem
> > (Maybe
> > > > BUG) ?
> > > >
> > > > >
> > > > > On Tuesday, November 27, 2001, at 12:39 AM, Costas Stergiou wrote:
> > > > >
> > > > > > Actually, when I mean "thread safe" I didn't mean "Java thread"
> > > > > > I meant "Request Safe" (actually it is thread safe also) but I
> don't
> > > > > > want to synchronize on the request tool of course.
> > > > > > But on a per-request basis, it is possible that the same instance
> of
> > the
> > > > > > tool is being used at the same time for more than one requests
> > > > > > (threads);
> > > > > > since a tool is only being taken from the Pool service and init'ed
> > but
> > > > > > there is no check that this tool is not being used by another
> > thread.
> > > > >
> > > > > Here's how I understand it. Someone correct me if I get this wrong.
> > > > >
> > > > > If the UIManager is configured to be used in the request scope, then
> > > > > a new UIManager object will be instantiated with each request (or
> > > > > pulled from the pool). So you get one UIManager object per request,
> > > > > and that should fix your problem.
> > > > >
> > > > > If it is configured for any other scope (which it is by default)
> then
> > > > > multiple requests (and therefore multiple threads) will be accessing
> > > > > the same instance of the UIManager. In this case, the UIManager
> needs
> > > > > to be modified for thread-safety.
> > > > >
> > > > > -Eric
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <mailto:[EMAIL PROTECTED]>
> > > > > For additional commands, e-mail:
> > > > <mailto:[EMAIL PROTECTED]>
> > > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > > > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
