Re: HTTPSession state

[Jeremy Boynes <jb...@apache.org>]

On Dec 6, 2006, at 10:17 AM, Jim Marino wrote:

>
> On Dec 6, 2006, at 10:04 AM, Jeremy Boynes wrote:
>
>> On Dec 6, 2006, at 9:05 AM, Jim Marino (JIRA) wrote:
>>
>>>     [ http://issues.apache.org/jira/browse/TUSCANY-973? 
>>> page=comments#action_12456118 ]
>>>
>>> Jim Marino commented on TUSCANY-973:
>>> ------------------------------------
>>>
>>> This needs to implement semantics similar to conversational  
>>> persistence and not just use the ServletContext as a container  
>>> for replication to work properly. At a certain point, the servlet  
>>> engine needs to be notified of a series of changes through  
>>> setAttribute. This is the same pattern we have with  
>>> conversational scope. We should also have a mechanism based on  
>>> intents that specify whether a particular instance should  
>>> failover, otherwise, we don't need to store it in the Servlet  
>>> context.
>>
>> I don't see this. The conversation scope here is the HTTP session  
>> and that is represented by the HTTPSession managed by the  
>> ServletContext. That seems an obvious place to be placing the state.
> Yes that is exactly what I am saying. However, notification that  
> state has changed needs to be done similar to the way we are  
> handling conversation persistence. None of this would use the  
> conversational scope container.

What notification? Change detection and/or optimization is something  
the servlet container needs to do as it own the session state. We  
need to delegate all state to it otherwise we will risk partial  
replication (i.e. broken data) if the servlet container decides to  
migrate the session. Efficiency of this is down to the servlet  
container's implementation.

>>
>> Intent is a separate issue and we don't even have basic support  
>> for that yet (or do we?). Even if we did we can map this to  
>> whether the servlet is <distributable> or not.
>>
> Servlet? Some components we may want fail-over for, some we may  
> not. We need a way to distinguish this.

Nice feature but for now we have none and doing this would give us an  
option. Cherry picking which at a component by component level can be  
done later (e.g. when we have something like the intent mechanism  
that allows the distinction to made).

--
Jeremy


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: HTTPSession state

[Jim Marino <jm...@myromatours.com>]

On Dec 6, 2006, at 10:27 AM, Jeremy Boynes wrote:

>
> What notification? Change detection and/or optimization is  
> something the servlet container needs to do as it own the session  
> state.
Yes I agree. I didn't say that :-) If a state change occurs on a  
session-scoped object, the servlet context needs to be notified. This  
is generally done by resetting the object into the servlet context.  
This doesn't have anything to do with replicating diffs (although a  
fail-over mechanism may do that, e.g. Terracotta). This should be  
done by Tuscany, probably after an invoke, not by the application  
since it would tie the app to the servlet container and is generally  
a PITA for developers (many web apps today don't get this right).

Jim

> We need to delegate all state to it otherwise we will risk partial  
> replication (i.e. broken data) if the servlet container decides to  
> migrate the session. Efficiency of this is down to the servlet  
> container's implementation.
>
>>>
>>> Intent is a separate issue and we don't even have basic support  
>>> for that yet (or do we?). Even if we did we can map this to  
>>> whether the servlet is <distributable> or not.
>>>
>> Servlet? Some components we may want fail-over for, some we may  
>> not. We need a way to distinguish this.
>
> Nice feature but for now we have none and doing this would give us  
> an option. Cherry picking which at a component by component level  
> can be done later (e.g. when we have something like the intent  
> mechanism that allows the distinction to made).
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org