Leo Sutic wrote on Thursday, October 23, 2003 10:35 AM:
<snipped>
> 2. Pooled/Shared - PerThread, in essence, but pooled in the
> background. Appears to client as Singleton. Automatic
> release when interface method is called (close ()), disposal
> when container shuts down. Re-aquire from pool when needed.
>
> private Connection connection = null;
>
> void service( ServiceManager manager ) {
> connection = (Connection) manager.lookup( Connection.ROLE );
> }
>
> void handleRequest() {
> Statement s = connection.prepareStatement (); //
> Aquire underlying connection from pool.
> ....
>
> connection.close(); // Drop connection back into pool. }
<snipped>
Here we have often in a webapp a similar scenario, but slightly different. You would
like to have Pooled/Request. The difference is that the thread itself is pooled by the
web server, but you would like to get new instaces of your classes for each request
(although you want always the same objects while the request is processed).
In my last project we had an even more complicated strategy, because we shared the
objects by multiple requests in the same context (i.e. from the same web page) and
cached them for a certain amount of time. IN consequence this meant that releaseing a
component was not necessarily the end of it. Naturally such special behaviour is
normally out of scope for a framework itself, but you should be able to integrate such
functionality easily. In our case we had to modify the DefaultContainer of Fortress
and had to copy & paste some of the internal code to made this work, because we found
no proper strategy to implement the behaviour using the standard API.
Regards,
J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
