Re: [Wonder-disc] SOLVED: Zombie sessions
Re: [Wonder-disc] SOLVED: Zombie sessions
- Subject: Re: [Wonder-disc] SOLVED: Zombie sessions
- From: Mike Schrag <email@hidden>
- Date: Wed, 22 Oct 2008 16:49:13 -0400
I'm using D2W, so I _have_ to have the session to generate the page
content. There's doesn't even appear to be a way to get a page from
the D2W factory without a session. So session isn't thread safe?
No mail from D2W?
So the "depending on how you're sending" is pretty crucial there :)
We actually send our emails out in a background thread, which
generates the component output in another thread, which would be
really dangerous if you're sharing a session. It's just a red flag to
look out for. I honestly have no idea about sending D2W-generated
emails or how to do that sans-sessions ... Not my department on that
one.
But this is really a crucial question for everyone, because the call
to generateResponse that is in ERJavaMail currently is writing to
the session's page cache already... so we're still mucking with the
session from a separate thread anyway, no?
? no? It's generating the response but that's totally independent of
a session. It's not a request-response loop, so there's no savePage
step of this process. There's only a session involved if you do
something that triggers a session to be created. That said, I suspect
you could ask your context for its session (if it has one)
and .sleep() it yourself and terminate it.
http://wiki.objectstyle.org/confluence/display/WO/Project+WONDER-Frameworks-ERJavaMail
Which I wrote :) I actually don't send with this method anymore, but
if you're sending from within your RR loop, this will work. I believe
our code creates a new request, cloning all the attributes we care
about on the way into the thread, creates a new context off of that,
and sends with that (without triggering session creation).
How else would we go about returning the proper context in the case
of a null return value after generate response does what you see in
that method to the context? Perhaps instead of cloning the context,
it should store the context._pageElement() value and reset it after
append to response is called?
I'll have to look more at what exactly you're running into ... You're
clearly using this differently than we are, as I don't run into any of
these problems. D2W probably throws a crazy monkey wrench into things.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden