Re: FW: Application Clustering
Re: FW: Application Clustering
- Subject: Re: FW: Application Clustering
- From: email@hidden
- Date: Thu, 13 Nov 2003 11:56:00 CDT
- Priority: 3 (Normal)
[demime could not interpret encoding binary - treating as plain text]
You could mean a lot of things by session failover. What I was assuming
was meant by it was a process something like this:
1) HTTP request comes in, to a particular instance, and a particular session.
2) That particular instance (or the session within that instance) no
longer exists.
3) So the request is sent to another instance and/or session again.
4) That other instance and/or session is able to properly respond to the
HTTP request, much the same way as the original instance/session would have.
That is not possible for an ordinary component-action URL, unless that
other instance and/or session has an intact version of the page cache,
was what I meant to explain in my last message. My point was that the
session page cache is NOT only used to "restore past pages". It is
NECCESARY to process ANY component-action based URL.
If you have another idea of 'session failover' in mind, then the page
cache may not get in your way, sure. If on session failover, you just
want to return them to the initial entry point of your app (even if
that's not where they thought they were going), but with certain session
data preserved from the failed session, sure, you can do that much more easily.
--Jonathan
On Thu, 13 Nov 2003 15:03:29 +1100 Marek Wawrzyczny wrote:
> That's true if by 'session failover' you mean the ability to restore
> past pages. I would be more interested in the ability to preserve any
> EO's the user has created or modified during the session. Should an
> instance fail, the user could then log back (or be transfered) into
> another instance of the application and resume work.
>
> On Thursday, Nov 13, 2003, at 04:59 Australia/Sydney,
> email@hidden wrote:
>
> <--- 8< original post trimmed >8 --->
>
> > 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.
> > --Jonathan
>
>
> Marek Wawrzyczny
>
> software engineer
> -------------------------->
> ish group pty ltd
> 7 Darghan St Glebe 2037 Australia
> phone +61 2 9660 1400 fax +61 2 9660 7400
> http www.ish.com.au | email email@hidden
_______________________________________________
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.