Pooling, costs, etc.

I am concerned about the complexity and expense of maintaining copies, however 
there is an element of "correctness" in creating these copies; it ensures that 
single-server and clustered behavior is the same ... just as a backup service 
in a cluster receives only copies of persistent properties, so will a single-
server; it ensures that the copy is the same for both.

There's still room to cheat (especially by changing properties of objects 
stored inside collections, when the collections are persistent properties), but 
it stands out more, and the behavior and timing is easier to describe.

Given that the vast majority of persistant properties will be String, Date, 
boolean, int, etc. (that is, easily identifyable immutables), the cost is 
actually not so great. 

The second-worst case in an object that is merely Serializable, since (deep) 
copying via Serialization is pretty darn expensive.

The worst case is getting an exception because a particular object type can't 
be copied.

I'll noodle on the idea of a "peer" that stores persistant state.  I'm not 
immediately seeing a way to do it that doesn't break most existing 
applications, and I'm concerned that creating new pages will involve a page 
spec, template and TWO classes (one for logic, one for data storage).  Seems 
less natural to me.

Again, on the applications I've worked on, persistent properties tend to be 
pretty rare and, when present, are immutable objects.  On the other hand, there 
are lots of people out there with much more experience actually building 
Tapestry applications than I do (perplexing, isn't it!).



--
[email protected]

http://tapestry.sf.net
> hi,
> 
> > > >The basic types, such as String, Number, Boolean work fine.  It
> > > >differentiates between mutable and immutable objects.  Immutable objects
> > > >are
> > > >String, Number, Boolean, java.util.Date (which is slightly fudging), Enum
> > > >and anything marked as IImmutable (a new marker interface for immutable
> > > >objects).
> > > >
> > > >Mutable objects are tougher since the persistance wants to keep an
> > isolated
> > > >copy of properties.  That is, fireObservedChange() results in a copy
> > being
> > > >made, and when a page is rolled back in a later request cycle, a copy (of
> > > >the copy) is made.
> > > >The problem is handling the copying of values.  At best, its going to do
> > a
> > > >shallow copy.  As a last resort, Serializable objects are serialized and
> > > >deserialzed (to make a deep copy).
> 
> I think exposing the pooling that has to happen inside tapestry to the
> average component developer is a mistake. It just opens up a way of
> shooting yourself in the foot, while giving very little advantage to app
> developers in general. And it seems now in order to make the semantics
> less confusing, you have to add more expensive and complicated behavior
> (copying) to the framework... Now I do agree that the pooling of
> expensive resources (templates, bindings, whatever else) is a goood
> thing... however, i would separate it in two: make components non-pooled
> and recreated all the time, and separate out the heavyweight portion into
> another class that does need to know about pooling. The lightweight
> component should delegate to the pooled instance when needed (Tapestry
> should estabilish the association between it and the peer).
> 
> eg. so a request could go somewhat like this:
> 
> Component c = ... // new instance
> ComponentPeer p = pool.getPeer(c);
> c.setPeer( p );
> // perform request...
> p.detach()
> c = null; // just forget about it...
> pool.returnPeer(p);
> 
> I think this would make developers have to think about a lot less
> "issues" that really have nothing to do with their application logic,
> only how the framework is built. Writing components would become more
> natural - you can use regular constructors and forget about detach and
> it's sideffects.
> 
> i hope this doesnt sound much sillier or less efficient than an intricate
> copying solution with special handling for immutables :)
> 
> best regards,
>     viktor
> -- 
>   
>   [email protected]
> 
> -- 
> http://fastmail.fm - Email service worth paying for. Try it for free
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Tapestry-contrib mailing list
> Tapestry-contrib-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/tapestry-contrib


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf