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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
