per-request life cycle <was> Re: Precondition support

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 12 Apr 2007 17:22:54 +0200

Hi Jerome,

After some mulling over of this you convinced me that a per-request life
cycle is the right thing to concentrate on. EE focused developers may
find it a bit odd because of servlets and session beans but i think it
makes it easier for developers.

I believe we can afford a more complex algorithm if it is possible to
scale out the application according to the RESTful style.

However, i do think some way to allow a resource to be singleton could
still be useful for specialized/optimal cases as the performance gains
can potentially be substantial. But i do not think this should be the
primiary case we concentrate on.


Jerome Louvel wrote:
> Paul,
>> Were you also proposing the status should be obtained via a
>> method as well?
> Yes, but the status is related to the Resource POJO, not to the
> Representation POJO. Order of calls could matter for resources as they have
> life cycles.
>>> Our
>>> experience with the Restlet API led us to make the Resource
>> class stateful.
>>> Stateful in the sense that the instances are not shared
>> between calls (they
>>> may eventually be pooled). This is different from the rest
>> of our upstream
>>> handlers which are generally stateless (all the changing
>> state is local to
>>> the executing thread).
>> IIRC Marc and I referred to that in previous emails as being
>> per-request
>> life-cycle.
> Ok, let's reuse your terminology. To me "per-request" makes sense as our
> main resource life-cycle.
>> Right. This is a key decision the EG needs to make as it impacts the
>> design of other things.
>> One very useful thing you can do with per-application life-cycle
>> (singleton or like servlet) is the caching resource
>> instances, and hence
>> state.
> Reusing resource instances across requests might be interesting from an
> optimization point of view but I'm not sure if the drawback in term of
> design simplicity of Resources is worth it.
> In the Restlet API we considered this extensively and finally decided that
> the performance gain (literally one instantiation as the supporting domain
> objects can be cached/reused) wasn't worth the pain.
> But, people are always free to implement resource pools/synchronized
> singletons or just rely on a normal Restlets (or Servlets to maintain the
> comparison).
>> This is used to great effect by Hudson [1], a RESTful
>> extensible
>> continuous integration Web application. We have used Hudson as a real
>> world use-case.
> Nice use case indeed.
>> We designed the API such that you define an object model of
>> relationships between resources based on the URI hierarchy. It is
>> possible for the application to choose whether to use
>> per-application or
>> per-request when moving through the object model as described
>> by the URI
>> path, which is consumed based on the URI templates. The closest
>> documentation i have to explain this is what Hudson uses,
>> called stapler
>> [2].
>> It creates a very flexible but intuitive way of building an
>> extensible
>> web application, for example see the section on stapler
>> polymorphism [3].
>> To get this more clearly across i think a demo would be best.
> Sure, it that can bring some light on this design point. Concerning the
> Restlet, I can point to an example showing the integration between Restlet
> Resources and domaing objects (a simple bookmark management application):
> ample/src/org/restlet/example/book/rest/ch7/
> markup
> Best regards,
> Jerome
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

| ? + ? = To question
    Paul Sandoz