You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Nick Airey <ni...@ihavemoved.com> on 2002/04/10 18:38:19 UTC
AbstractAction Poolable?
Hello everyone,
I have also posted this question on cocoon-users today - apologies to
those who have seen this there:
Currently AbstractAction doesn't implement Poolable (itself or in base
classes). That explains why there are no examples of pooled actions
in the current sample sitemap. Also, the Poolable interface is simply a
marker, so it is trivial to make my action "poolable".
So I did a quick test by simply:
a) making my action implement Poolable, and
b) adding pool-max, pool-min, pool-grow to the sitemap definition for
that action
And it works. :-)
(well, at least, it seems to work. I can see the pool being created, and
an element being retrieved as needed) My other actions are
created/destroyed every time.
So does anyone have any ideas why say AbstractAction doesn't implement
poolable? Is there something I'm missing that will bite me?
Regards,
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AbstractAction Poolable?
Posted by Nick Airey <ni...@ihavemoved.com>.
On Wed, 2002-04-10 at 17:48, Berin Loritsch wrote:
>
> It used to be THreadSafe. In fact, most of the actions should be marked
> ThreadSafe--that way there is only one instance.
Well that's interesting, and makes sense. So my actions will be either
Poolable or Threadsafe.
The AbstractAction
> should not implement any lifestyle interfaces at all. Each concrete
> action should decide its lifestyle directly.
>
Ok fine.
Thanks for your help.
Nick.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AbstractAction Poolable?
Posted by Torsten Curdt <tc...@dff.st>.
> > Peter, could you elaborate a bit more... I haven't seen any need for a
> > poolable action yet. Just curious...
>
> The action doesn't *have* to be poolable, but it makes the code cleaner as I
> don't have to pass as many variables around as method parameters.
>
> My FormValidatorAction validates all request params into valid and invalid
> buckets, rather than passing those buckets as method params I they are just
> class-level variables that the methods can access as needed.
>
> It used to be ThreadSafe before actions could be Poolable, but when I was
> refactoring it, it was much cleaner to make it Poolable.
ok... that's what I thought ;-)
Thanks
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AbstractAction Poolable?
Posted by Peter Royal <pr...@managingpartners.com>.
On Thursday 11 April 2002 10:18 am, Torsten Curdt wrote:
> > For an example, I have my FormValidatorAction which is Poolable, but if
> > that succeeds either a FormAdditionAction or FormUpdatingAction runs,
> > which either adds or updates data. Since these are fairly simple they are
> > all implemented as ThreadSafe.
>
> Peter, could you elaborate a bit more... I haven't seen any need for a
> poolable action yet. Just curious...
The action doesn't *have* to be poolable, but it makes the code cleaner as I
don't have to pass as many variables around as method parameters.
My FormValidatorAction validates all request params into valid and invalid
buckets, rather than passing those buckets as method params I they are just
class-level variables that the methods can access as needed.
It used to be ThreadSafe before actions could be Poolable, but when I was
refactoring it, it was much cleaner to make it Poolable.
-pete
--
peter royal -> proyal@managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AbstractAction Poolable?
Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 11 Apr 2002, Peter Royal wrote:
> On Thursday 11 April 2002 08:17 am, Ivelin Ivanov wrote:
> > I see.
> > I didn't realize actions are generally used for things different from user
> > input handling.
>
> For an example, I have my FormValidatorAction which is Poolable, but if that
> succeeds either a FormAdditionAction or FormUpdatingAction runs, which either
> adds or updates data. Since these are fairly simple they are all implemented
> as ThreadSafe.
Peter, could you elaborate a bit more... I haven't seen any need for a
poolable action yet. Just curious...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AbstractAction Poolable?
Posted by Peter Royal <pr...@managingpartners.com>.
On Thursday 11 April 2002 08:17 am, Ivelin Ivanov wrote:
> I see.
> I didn't realize actions are generally used for things different from user
> input handling.
For an example, I have my FormValidatorAction which is Poolable, but if that
succeeds either a FormAdditionAction or FormUpdatingAction runs, which either
adds or updates data. Since these are fairly simple they are all implemented
as ThreadSafe.
But we need a best-pratices document to explain this kind of thing :)
-pete
--
peter royal -> proyal@managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AbstractAction Poolable?
Posted by Ivelin Ivanov <iv...@apache.org>.
I see.
I didn't realize actions are generally used for things different from user
input handling.
----- Original Message -----
From: "Peter Royal" <pr...@managingpartners.com>
To: <co...@xml.apache.org>
Sent: Wednesday, April 10, 2002 10:00 PM
Subject: Re: AbstractAction Poolable?
> On Wednesday 10 April 2002 10:59 pm, Ivelin Ivanov wrote:
> > Not being an Avalon specialist, I think that Nick has a good point.
> > Why shouldn't the AbstractAction be poolable?
> > It's been an inconvenience that Strut's Actions must be thread safe.
> > Actions usually deal with forms and tend to hold on to a bunch of
stateful
> > objects. (validatiors, a list of timezones, a list of countries, user
> > locale, session, request, etc.)
> > It feels cleaner when you don't need to pass these objects around during
an
> > Action execution.
> > Of course you can use ThreadLocal and get away, but it'll make UI
coders'
> > lifes easier if they don't need to think threads. Memory is not as
> > expensive as it used to be ...
>
> With AbstractAction *not* having a lifestyle interface (Poolable /
> ThreadSafe) the component author that subclasses AbstractAction then has
the
> choice of what to use.
>
> Yes, you are right for form validation. My form validation action is
> Poolable, but its the only one that I've got that's poolable. The rest of
my
> actions are ThreadSafe because they're much simpler and don't need to keep
as
> much stateful information (or it can be easily passed as method
parameters).
>
> The current way is best because it gives you the action author the power
to
> best decide what to use for the current situation :)
> -pete
>
> --
> peter royal -> proyal@managingpartners.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AbstractAction Poolable?
Posted by Peter Royal <pr...@managingpartners.com>.
On Wednesday 10 April 2002 10:59 pm, Ivelin Ivanov wrote:
> Not being an Avalon specialist, I think that Nick has a good point.
> Why shouldn't the AbstractAction be poolable?
> It's been an inconvenience that Strut's Actions must be thread safe.
> Actions usually deal with forms and tend to hold on to a bunch of stateful
> objects. (validatiors, a list of timezones, a list of countries, user
> locale, session, request, etc.)
> It feels cleaner when you don't need to pass these objects around during an
> Action execution.
> Of course you can use ThreadLocal and get away, but it'll make UI coders'
> lifes easier if they don't need to think threads. Memory is not as
> expensive as it used to be ...
With AbstractAction *not* having a lifestyle interface (Poolable /
ThreadSafe) the component author that subclasses AbstractAction then has the
choice of what to use.
Yes, you are right for form validation. My form validation action is
Poolable, but its the only one that I've got that's poolable. The rest of my
actions are ThreadSafe because they're much simpler and don't need to keep as
much stateful information (or it can be easily passed as method parameters).
The current way is best because it gives you the action author the power to
best decide what to use for the current situation :)
-pete
--
peter royal -> proyal@managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AbstractAction Poolable?
Posted by Berin Loritsch <bl...@apache.org>.
Ivelin Ivanov wrote:
> Not being an Avalon specialist, I think that Nick has a good point.
> Why shouldn't the AbstractAction be poolable?
> It's been an inconvenience that Strut's Actions must be thread safe.
> Actions usually deal with forms and tend to hold on to a bunch of stateful
> objects. (validatiors, a list of timezones, a list of countries, user
> locale, session, request, etc.)
> It feels cleaner when you don't need to pass these objects around during an
> Action execution.
> Of course you can use ThreadLocal and get away, but it'll make UI coders'
> lifes easier if they don't need to think threads. Memory is not as expensive
> as it used to be ...
>
> Please correct me if my point makes little sence.
>
> Ivelin
Ivelin, you missed the point of the response. Cocoon actions are not
required to be ThreadSafe (they *used* to be, but not now). When
someone introduced dynamically generated Actions (can't remember who)
we decided that it was proper to use the same decision process for all
components.
Choosing whether a component is ThreadSafe, Poolable, or requiring the
Factory method is an **implementation** detail. It is an error to
implement multiple lifestyle methods, and the ECM
(ExcaliburComponentManager) will throw an exception. Make no mistake,
the AbstractAction should not implement *any* lifestyle interface.
Period.
When you write your action, the final implementation implements the
correct lifestyle interface.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AbstractAction Poolable?
Posted by Ivelin Ivanov <iv...@apache.org>.
Not being an Avalon specialist, I think that Nick has a good point.
Why shouldn't the AbstractAction be poolable?
It's been an inconvenience that Strut's Actions must be thread safe.
Actions usually deal with forms and tend to hold on to a bunch of stateful
objects. (validatiors, a list of timezones, a list of countries, user
locale, session, request, etc.)
It feels cleaner when you don't need to pass these objects around during an
Action execution.
Of course you can use ThreadLocal and get away, but it'll make UI coders'
lifes easier if they don't need to think threads. Memory is not as expensive
as it used to be ...
Please correct me if my point makes little sence.
Ivelin
----- Original Message -----
From: "Torsten Curdt" <tc...@dff.st>
To: <co...@xml.apache.org>
Sent: Wednesday, April 10, 2002 11:56 AM
Subject: Re: AbstractAction Poolable?
> On Wed, 10 Apr 2002, Berin Loritsch wrote:
>
> > Nick Airey wrote:
> > > Hello everyone,
> > >
> > >
> > > I have also posted this question on cocoon-users today - apologies to
> > > those who have seen this there:
> > >
> > >
> > > Currently AbstractAction doesn't implement Poolable (itself or in base
> > > classes). That explains why there are no examples of pooled actions
> > > in the current sample sitemap. Also, the Poolable interface is simply
a
> > > marker, so it is trivial to make my action "poolable".
> > >
> > > So I did a quick test by simply:
> > >
> > > a) making my action implement Poolable, and
> > > b) adding pool-max, pool-min, pool-grow to the sitemap definition for
> > > that action
> > >
> > >
> > > And it works. :-)
> > >
> > > (well, at least, it seems to work. I can see the pool being created,
and
> > > an element being retrieved as needed) My other actions are
> > > created/destroyed every time.
> > >
> > >
> > > So does anyone have any ideas why say AbstractAction doesn't implement
> > > poolable? Is there something I'm missing that will bite me?
> >
> >
> > It used to be THreadSafe. In fact, most of the actions should be marked
> > ThreadSafe--that way there is only one instance. The AbstractAction
> > should not implement any lifestyle interfaces at all. Each concrete
> > action should decide its lifestyle directly.
>
> ups.. you were faster ;-)
> -
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AbstractAction Poolable?
Posted by Torsten Curdt <tc...@dff.st>.
On Wed, 10 Apr 2002, Berin Loritsch wrote:
> Nick Airey wrote:
> > Hello everyone,
> >
> >
> > I have also posted this question on cocoon-users today - apologies to
> > those who have seen this there:
> >
> >
> > Currently AbstractAction doesn't implement Poolable (itself or in base
> > classes). That explains why there are no examples of pooled actions
> > in the current sample sitemap. Also, the Poolable interface is simply a
> > marker, so it is trivial to make my action "poolable".
> >
> > So I did a quick test by simply:
> >
> > a) making my action implement Poolable, and
> > b) adding pool-max, pool-min, pool-grow to the sitemap definition for
> > that action
> >
> >
> > And it works. :-)
> >
> > (well, at least, it seems to work. I can see the pool being created, and
> > an element being retrieved as needed) My other actions are
> > created/destroyed every time.
> >
> >
> > So does anyone have any ideas why say AbstractAction doesn't implement
> > poolable? Is there something I'm missing that will bite me?
>
>
> It used to be THreadSafe. In fact, most of the actions should be marked
> ThreadSafe--that way there is only one instance. The AbstractAction
> should not implement any lifestyle interfaces at all. Each concrete
> action should decide its lifestyle directly.
ups.. you were faster ;-)
-
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AbstractAction Poolable?
Posted by Berin Loritsch <bl...@apache.org>.
Nick Airey wrote:
> Hello everyone,
>
>
> I have also posted this question on cocoon-users today - apologies to
> those who have seen this there:
>
>
> Currently AbstractAction doesn't implement Poolable (itself or in base
> classes). That explains why there are no examples of pooled actions
> in the current sample sitemap. Also, the Poolable interface is simply a
> marker, so it is trivial to make my action "poolable".
>
> So I did a quick test by simply:
>
> a) making my action implement Poolable, and
> b) adding pool-max, pool-min, pool-grow to the sitemap definition for
> that action
>
>
> And it works. :-)
>
> (well, at least, it seems to work. I can see the pool being created, and
> an element being retrieved as needed) My other actions are
> created/destroyed every time.
>
>
> So does anyone have any ideas why say AbstractAction doesn't implement
> poolable? Is there something I'm missing that will bite me?
It used to be THreadSafe. In fact, most of the actions should be marked
ThreadSafe--that way there is only one instance. The AbstractAction
should not implement any lifestyle interfaces at all. Each concrete
action should decide its lifestyle directly.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AbstractAction Poolable?
Posted by Torsten Curdt <tc...@dff.st>.
On 10 Apr 2002, Nick Airey wrote:
> Hello everyone,
>
>
> I have also posted this question on cocoon-users today - apologies to
> those who have seen this there:
>
>
> Currently AbstractAction doesn't implement Poolable (itself or in base
> classes). That explains why there are no examples of pooled actions
> in the current sample sitemap. Also, the Poolable interface is simply a
> marker, so it is trivial to make my action "poolable".
>
> So I did a quick test by simply:
>
> a) making my action implement Poolable, and
> b) adding pool-max, pool-min, pool-grow to the sitemap definition for
> that action
>
>
> And it works. :-)
>
> (well, at least, it seems to work. I can see the pool being created, and
> an element being retrieved as needed) My other actions are
> created/destroyed every time.
>
>
> So does anyone have any ideas why say AbstractAction doesn't implement
> poolable? Is there something I'm missing that will bite me?
It depends on your implementation if poolable is really necessary. So
marking the AbstractAction poolable would make a lot of action poolable
that might be even threadsafe! which is of course preferred..
Hope this helps...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org