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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
