Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: RequestLifecycle components
Date: Wed, 22 Oct 2003 18:30:41 +0200
Message-ID: <84F0A43A4248CE45B5C0E20F4C40779C6008F1@naomi.webworks.nl>
Thread-Topic: RequestLifecycle components
Thread-Index: AcOYt3bcNQCRGZp/TRGqTVRwDNykDwAAF0Rg
From: "Unico Hommes" <Unico@hippo.nl>
To: <dev@cocoon.apache.org>

=20

Berin Loritsch wrote:
>=20
> Unico Hommes wrote:
>=20
> >=20
> >> Ok, anyway, we could keep the GRL which can be modelled in=20
> fortress=20
> >> using a thread component (one component per thread), but=20
> skip the RLC=20
> >> which caused a lot of trouble to get it working and which=20
> might still=20
> >> cause us more trouble than it's worth.
> >>=20
> >=20
> >=20
> > Hmm, AFAIU declaring a per-thread lifecycle is not enough,=20
> the handler=20
> > that implements this in Fortress is not aware of recyclable=20
> > components. What it does is give out a different instances for=20
> > different threads and the same instance for the same thread=20
> that's it.=20
> > There still needs to be some custom provision for handling=20
> Recyclables=20
> > our request type situation. But I know Berin knows more about this.
> >=20
>=20
> Why would you recycle if you aren't pooling? =20

But I *am* pooling.  What I meant was a situation where the same
instance is handed out to the same thread until it is released. Then it
can be put back into the pool again.

> You can't (or=20
> at least shouldn't) rely on recycle() being called--even in a=20
> pooled environment.
>=20

OK.

> The whole purpose of the recycle() method is to return the=20
> component to an initial state *if* it is pooled and reused. =20
> If the component is created and destroyed (SIngleThreaded in=20
> old ECM parlance, or when the pool is overloaded), then the=20
> recycle() method is never called once.  And that is with=20
> current ECM code.
>=20

I know. And so it doesn't make much sense to assign a poolable component
with a per-thread lifestyle handler.

> Do not rely on recycle() for any transactional boundary or=20
> you *will* find your application malfunctioning under load.
>=20

OK.

-- Unico

> --=20
>=20
> "They that give up essential liberty to obtain a little=20
> temporary safety
>   deserve neither liberty nor safety."
>                  - Benjamin Franklin
>=20
>=20
>=20