Re: FW: Application Clustering
Re: FW: Application Clustering
- Subject: Re: FW: Application Clustering
- From: email@hidden
- Date: Wed, 12 Nov 2003 11:59:18 CDT
- Priority: 3 (Normal)
[demime could not interpret encoding binary - treating as plain text]
A component-action based URL looks something like the following.
Everything in square
brackets is a "label" I'm putting in, it wouldn't ordinarily appear in
the URL like that.
http://hostname/cgi-bin/WebObjects/AppName.woa/[instance #]/wo/[sessionID]/
[contextID].[elementID]
Now let's go through a somewhat simplified description of how WO will
process a HTTP
request to this URL. Let's assume a simple hyperlink, not a form submit
(a form submit is
basically similar, but involves a takeValuesFromRequest phase too, which
doesn't concern us
here). First, the adaptor gets it, looks at the [instance #], and then
forwards the HTTP
request to the proper instance.
Now the proper instance has it. It looks at the [sessionID], and restores
the proper session,
and calls invokeAction() on it. The WOSessoin looks at the [contextID]
(which is a number,
like '12'), which allows it to restore a _particular_ WOComponent
instance from the page
cache. This particular WOComponent object, the one that generated that
URL in the first
place is restored, and has invokeAction() called. That particular
WOComponent object will
then use the [elementID] (which may look, for example, like
"0.3.0.0.12.3") and uses the
elementID to determine which action method is specified. That action
method is invoked,
and generally returns a WOComponent. That returned WOComponent is made
to generate
a response, and that response is returned to the browser.
The important fact here is that a component-action URL only has meaning
in the context of a
certain session, with an intact page cache. For instance, if the
[contextID] in the URL can not
be found in the session's page cache, that's when you get the
'backtracked too far'
exception---a component-action can not be evaluated unless the
[contextID] can be used to
restore a page from the session page cache. Without this, a
component-action URL is
meaningless, there's no way to know what it's supposed to do, what action
is supposed to be
invoked, what page is supposed to be returned.
Hope this helps explain why 'session failover' for a component-action
based URL will require
an intact page cache in the receiving instance/session. A Direct Action
URL is not subject to
this----a Direct Action URL does not depend on a session page cache for
it's meaning (even
if a session is present, it's page cache is not inherently neccesary to
determine the meaning
of a DA URL). Alternately, you could try to put additional information
in every URL, perhaps
as key/values on the end, that would provide meaning about what page
should be returned
even in the absence of an intact page cache, and this additional meaning
could theoretically
be used in a session-failover situation. This would be kind of tricky,
but is probably possible
for a relatively simple application with limited functionality----coming
up with a system like
this that would work for any possible application code in any possible
component-action
situation would probably be so impractical as to be ruled out.
For those interested in learning how the component-action URL processing
happens, there's
actually one important piece of information, further complicating things,
that I haven't yet
mentioned. For the default WO setting of
pageRefreshOnBacktrackEnabled==true, the
WOSession actually caches which WOComponent object (a _particular_ WOComponent
object, not just a class or type) was _returned_ by the action method
invoked by the
component-action URL. If the exact same URL is requested a second (or
third, etc) time,
WO won't go through the process of calling invokeAction on the
[contextID] on the URL.
Instead, WO will retrieve the _returned_ WOComponent from it's cache, and
simply have
this WOComponent generate another response, and return that response to
the browser.
This avoids invoking a given action method more than once for a browser
refresh, or
browser double-submit (user clicks the link twice), or some kinds of
browser backtracking.
This "response cache", unlike the ordinary page cache, does not have any
API exposed,
and is hardly documented at all. It's existence is mentioned, but exactly
how it works, we're
not told, and I do not know beyond what I have said here. This feature
will not make
'session failover' any easier, but could potentially make 'session
failover' for component-
action URLs even more dificult, if you want to preserve this
functionality on session failover.
--Jonathan
On Wed, 12 Nov 2003 14:21:06 +0000 email@hidden wrote:
> Hi Jonathan
>
> On Tuesday, November 11, 2003, at 12:31 am,
> email@hidden wrote:
>
> > There are a couple things to consider.
> >
> > 1) You want to maintain user state outside of the application instance
> > memory, so it can be restored from another instance even if the
> > instance
> > fails. The way to do this would be by writing your own WOSessionStore
> > that stored the WOSession and everything that came off it in some
> > external store (db or file system). Theoretically, that's possible,
> > and
> > some Apple documentation at least used to suggest this as a
> > possibility.
> > Practically.... I think it would require an awful lot of developer
> > hours
> > (with the developers behind them being relatively
> > knowledgable/experienced at WO) to make this work in general for any
> > component-action based application.
> >
> > The most challenging part is going to be about the page cache, storing
> > the page cache externally, and storing all the WOComponents (with
> > state)
> > in the page cache externally.
>
> I don't understand that, why do you want to store the WOComponents
> present in the page cache?
>
> If the user falls back to another instance, what you need is to
> transfer the session data to this instance.
> This is done by keeping the data in an external, persistant store that
> is not wiped out when the instance fails.
>
> The components can be generated again as needed.
>
> -- Denis.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.