Re: Picking up .wo changes
Re: Picking up .wo changes
- Subject: Re: Picking up .wo changes
- From: Anders F Björklund <email@hidden>
- Date: Sat, 7 Jun 2003 17:24:23 +0200
Chuck Hill wrote:
And you *will* need to lock if yoru LRP does anything with EOF.
I find that this snippet comes in handy in such situations:
try
{
ec.lock();
// do stuff with EOs here
}
finally
{
ec.unlock();
}
Accessing the session from such a WOLongResponsePage is also somewhat
tricky...
(making the "conversion" from a regular WOComponent to a
WOLongResponsePage tedious)
I recall Apple recommending running several app instances instead
(and buying a few more Apple server boxes while you were at it :-)
:-) Gotta sell that hardware! I think this is the reccomendation and
the easiest way to go. It does not help with long running requests
though.
Then again, running several instances has some major effect on how the
EOF caching works (need some ChangeNotification framework?)
and unless you switch WOSessionStore and enable session "distribution"
it will still lock all particular requests to *that* instance.
(unless you can run either sessionless or distributed, sessions will
"home" back to the instance that created them - or "time out")
And the problems are now moved from multi-threaded, to multi-process or
even multi-host (which means that they'll be in another JVM).
So now session objects need to be Serialized for marshalling over to
another application instance, and such. Lots of fun, for sure!
Going from one instance to multiple instances does require some careful
planning and consideration too. It doesn't happen by itself.
This is also the reason why you *shouldn't* store user preferences or
shopping carts in the session directly...
Mostly since the default session is already filled with cached
components, component widget state and other cruft.
(usually a lot more things than the important ones you really want to
permanently store on a user basis)
Better to store those in a separate entity in the database, and just
*cache* that in the session (temporarily).
Then you can recover those "session" variables in case the session gets
lost (either times out or moves to another instance)
And you probably want to still keep the session timeout rather low
(<=1hr), to reclaim some of that application memory wasted.
Also what is a "long request" is not easy to determine... As your
application gets busy and gets more visitors,
more and more components become "long requests" (since they now take
too long time to complete before timeout).
Do you then need to rewrite those as LRP as well ? Maybe easier to run
with ConcurrentRequests for that case.
It's still possible to write such applications, of course. Just a
little different from the "default" WebObjects setup...
(and I don't think it is described very well in the documentation,
which mostly focuses on the simplest cases?
With most servlet examples I've seen, they start with multi-threading
and connection-pooling almost right away)
That's enough off-topic ramblings for now,
--anders
_______________________________________________
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.