[EMAIL PROTECTED] wrote:
>
> Please,
>
> Forgive me if this topic has been discussed earlier. I'm quite new with
> Turbine and just started more serious work with modules.
>
> The RunData object is a key object all around Turbine and I think that its
> correct use could be clarified and its internal state better protected by
> making it an interface instead of an object. Now it contains fields that are
> partly public and partly private. In addition, also most public fields have
> both getters and setters. Yet some of the fields are quite clearly meant to
> be initialized only by the factory and should not be changed during
> processing.
All fields should be private. This was one of the first classes
implemented in Turbine. Some applications were using the public fields
so the decision was made to leave the fields public for a period of time
after the getters/setters were added. That period has turned out to be
much longer than it really needed to be. The fields should be private.
>
> Examples of interfaces used for corresponding purposes are
> HttpServletRequest, HttpServletResponse and HttpSession. An additional
> benefit from the change would be the possibility to make implementations
> support new functionality, e.g. pooling. As Tomcat pools connectors, request
> and response implementations and Turbine caches modules, RunData is one of
> the base objects, which is allocated again for every request. For heavy
> loaded applications, balancing of memory usage is a key issue.
Pooling objects has been circulating around my mind for the last couple
weeks, I have to keep telling myself to finish the 4 or 5 changes I
already have in progress. I was thinking it should be reasonably
straightforward to modify Turbine's connection pooling service to create
a object pooling service (in addition to the current service, not
replacing it.) Turbine's connection pool is set up as a collection of
pools for different db's and this should translate well to a collection
of pools of different objects. But I have not got into the details, so
feel free to educate me on the futility of developing a general object
pool service.
>
> I tried this by creating a RunData interface, renaming the original RunData
> to TurbineRunData and making all of its fields private. I added pooling
> support both to TurbineRunData and RunDataFactory. Only five classes in
> Turbine (01/31/2001) were referencing the public fields, otherwise
> compilation was OK and running some basic Velocity modules worked without
> problems.
>
> The classes that required changes were related to error handling (Error,
> VelocityErrorScreen, WebMacroErrorScreen) using the stackTrace and
> stackTraceException fields. I changed the classes to use getters/setters
> instead. In addition, DefaultBottomNavigation used the varDebug field, which
> I also moved behind a getter. The Turbine class was changed to return the
> used RunData back to the factory to be recycled. For pooling support, I
> added a Recyclable interface and a RecyclableSupport class for objects to be
> pooled and a BoundedBuffer class for implementing the pool.
>
> The RunData interface is attached and I would be happy to provide the rest,
> if this gets support. Comments?
It certainly has my support. +1. Please contribute your code and also
please comment on implementation as a service.
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
