Re: FW: Application Clustering
Re: FW: Application Clustering
- Subject: Re: FW: Application Clustering
- From: email@hidden
- Date: Mon, 10 Nov 2003 19:31:38 CDT
- Priority: 3 (Normal)
[demime could not interpret encoding binary - treating as plain text]
On Mon, 10 Nov 2003 16:22:01 -0500 "Karl Gretton" wrote:
> We are moving an application to a cluster of Xserve's running WO
> 5.2.2 under
> Panther Server. While WO does some application server / instance
> level load
> balancing, what facilities are available in the event of the failure of an
> instance?
Essentially none.
> Is there a session level failover API or some automatic functionality to
> maintain user state?
No.
> Also, we have extensive caching taking place within the application
> and also
> use shared editing contexts. Are there any automatic facilities for
> synchronizing cached objects or objects in a shared editing context? If
> not, does anyone have any particular thoughts on the best way to achieve
> this within WO?
There are not any such automatic functionalities.
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.
If you can restrict your application to direct actions only, writing this
external-storing WOSessionStore becomes much easier, and within the realm
of possiblity. A DA-only app CAN still have a session. But it won't have
a session page cache, so (I think!) you would only need to worry about
serializing any state information you have explicitly added to your
WOSession sub-class. That should be much more practical and
do-able----but writing a complex app with only Direct Actions can be a
pain. component based actions and stored component state gives you a lot
of power for quickly and easily writing an app, that you lose if you
restrict yourself to only DAs (even with a session).
2. Your second question is "Are there any automatic facilities for
synchronizing cached objects or objects in a shared editing context?"
There are not, but... it doesn't seem to me that you would need to do
this to implement an instance failure/session-level failover. But I
could be missing something. Why do you think this would be neccesary?
One would need to think through the consequences of this NOT being there
for session failover, but I'm not thinking of any problematic
consequences myself.
If you DO need to implement this sort of thing, either for
session-failover purposes or other purposes, there is a Change
Notification framework in Project Wonder that would provide you with a
starting point. And possibly do everything you need right as it is,
depending on exactly what you need, I'm not sure what you need.
--Jonathan
>
>
>
> In the past I have used EJB facilities (Message Beans) or simple SOAP
> calls
> to registered servers but this seems like a lot of work. Other app
> servers
> such as WebLogic and WebSphere have APIs for handling both of these
> features.
>
>
>
> Any thoughts would be welcome.
>
>
> Regards,
>
>
>
> Karl
> _______________________________________________
> 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.
_______________________________________________
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.