I dunno, think you are up to it?
I can't reproduce this, btw ... I vote that you're lying to me.
Remember null vs context().page()? :-P
Man ... You're wrong in ONE multiyear feud and they never let you live
it down.
ms
___
Do not post admin requ
On Dec 1, 2008, at 9:41 PM, Mike Schrag wrote:
I dunno, think you are up to it?
I can't reproduce this, btw ... I vote that you're lying to me.
Remember null vs context().page()? :-P
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for devel
Am 02.12.2008 um 00:50 schrieb Chuck Hill:
On Dec 1, 2008, at 3:38 PM, Andrew Lindesay wrote:
Hello Mike;
I guess that's only really possible through a slip-up in the top-
level exception handling... hmmm... thanks.
Or sleep() or terminate() not calling super or throwing an
exception.
I dunno, think you are up to it?
I can't reproduce this, btw ... I vote that you're lying to me.
ms
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Up
On Dec 1, 2008, at 6:01 PM, Mike Schrag wrote:
Why doesn't terminate check in the session?
It does check in the session, but because it has terminated, the
request that is blocked on the session checkout never gets unblocked.
If it checks in the session, it should .notify() the TimeoutEntry
Why doesn't terminate check in the session?
It does check in the session, but because it has terminated, the
request that is blocked on the session checkout never gets unblocked.
If it checks in the session, it should .notify() the TimeoutEntry (the
code looks relatively straightforward)
Won
On Dec 1, 2008, at 5:13 PM, Mike Schrag wrote:
This bug happens when multiple requests for a session come in
before the first request completes (Ajax on the page can cause
this) and the first request calls terminate() on the session (e.g.
from a log out link or in response to an exception
This bug happens when multiple requests for a session come in before
the first request completes (Ajax on the page can cause this) and
the first request calls terminate() on the session (e.g. from a log
out link or in response to an exception during request processing).
The session terminat
On Dec 1, 2008, at 5:01 PM, Mike Schrag wrote:
I guess that's only really possible through a slip-up in the top-
level exception handling... hmmm... thanks.
yeah
Or sleep()
yeah
or terminate() not calling super or throwing an exception
yeah
. Or two requests for a session coming very
I guess that's only really possible through a slip-up in the top-
level exception handling... hmmm... thanks.
yeah
Or sleep()
yeah
or terminate() not calling super or throwing an exception
yeah
. Or two requests for a session coming very close together and the
first calling terminate(
On Dec 1, 2008, at 3:38 PM, Andrew Lindesay wrote:
Hello Mike;
I guess that's only really possible through a slip-up in the top-
level exception handling... hmmm... thanks.
Or sleep() or terminate() not calling super or throwing an exception.
Or two requests for a session coming very clo
Hello Mike;
I guess that's only really possible through a slip-up in the top-level
exception handling... hmmm... thanks.
cheers.
Does anybody know what the monitor object for this synchronised-
block might be for?
[1] java.lang.Object.wait (native method)
[2] java.lang.Object.wait (Object
Does anybody know what the monitor object for this synchronised-
block might be for?
[1] java.lang.Object.wait (native method)
[2] java.lang.Object.wait (Object.java:474)
[3] com.webobjects.appserver.WOSessionStore.checkOutSessionWithID
(WOSessionStore.java:191)
It means a session didn't ge
Hello;
Does anybody know what the monitor object for this synchronised-block
might be for?
[1] java.lang.Object.wait (native method)
[2] java.lang.Object.wait (Object.java:474)
[3] com.webobjects.appserver.WOSessionStore.checkOutSessionWithID
(WOSessionStore.java:191)
I have no othe
14 matches
Mail list logo
