Is the session terminated if this happens? I think that is what
should happen. How long does it wait before deciding to give up
waiting for the session to be checked in?
Thanks
Chuck
On Jun 7, 2009, at 4:12 PM, Mr. Pierre Frisch wrote:
I have actually rewritten this code in WO 5.6 and the
I have actually rewritten this code in WO 5.6 and the sessions
deadlock should be something of the past. The thing is that there is
no need to way forever for a session to check in. The new approach is
to have a semaphore and timeout so that threads get released and do
not wait forever on a
On May 28, 2009, at 7:41 AM, Johan Henselmans wrote:
Second approach would be to store all the session information (the
products, user info etc) in a database table, and, once the user
gets back from the payment, pickup from there, and restore it's
previous information. But that might mean
Am 28.05.2009 um 15:49 schrieb Kieran Kelleher:
Only reason I wouldn't is when I am trying to troubleshoot a problem
with the awesome ERXSessionStoreDeadlockDetection. Pity it does not
work with concurrenr request handling on. It probably is just not
possible. No way ;-)
Nope, it's not po
Only reason I wouldn't is when I am trying to troubleshoot a problem
with the awesome ERXSessionStoreDeadlockDetection. Pity it does not
work with concurrenr request handling on. It probably is just not
possible. No way ;-)
On May 28, 2009, at 9:30 AM, Mike Schrag wrote:
Just to add some c
Am 28.05.2009 um 15:30 schrieb Mike Schrag:
Just to add some caution: be sure to run either multi-threaded or
see that you don't have long requests that may block the app for a
longer time.
also just always run multithreaded. why wouldn't you ...
Come to think of it, just turning MT
This IS a consideration of a vulnerability if you LOSE that instance
inbetween these operations -- Patrick's suggestion of storing as
much as possible in the db would cover you for that.
er.. "This" = "There"
ms
___
Do not post admin requests to th
you'll either be using cookies, which species sessionid + instance
id, or you'll be using URL encodingand your direct action URL will
have both the instance ID as well as ?wosid=xxx in the URL (http://yoursite/cgi-bin/WebObjects/YourApp.woa/instanceid/daname?wosid=xxx
) ... should work fine
Le 09-05-28 à 09:33, Mike Schrag a écrit :
you'll either be using cookies, which species sessionid + instance
id, or you'll be using URL encodingand your direct action URL will
have both the instance ID as well as ?wosid=xxx in the URL (http://yoursite/cgi-bin/WebObjects/YourApp.woa/instanc
you'll either be using cookies, which species sessionid + instance
id, or you'll be using URL encodingand your direct action URL will
have both the instance ID as well as ?wosid=xxx in the URL (http://yoursite/cgi-bin/WebObjects/YourApp.woa/instanceid/daname?wosid=xxx
) ... should work fine
Just to add some caution: be sure to run either multi-threaded or
see that you don't have long requests that may block the app for a
longer time.
also just always run multithreaded. why wouldn't you ...
ms
___
Do not post admin requests to the
On 28 May 2009, at 13:57, Anjo Krank wrote:
Just to add some caution: be sure to run either multi-threaded or
see that you don't have long requests that may block the app for a
longer time.
Otherwise the adaptor will happily redirect you callback to another
instance - where the session m
Just to add some caution: be sure to run either multi-threaded or see
that you don't have long requests that may block the app for a longer
time.
Otherwise the adaptor will happily redirect you callback to another
instance - where the session most likely will not be known...
Cheers, Anjo
you'll either be using cookies, which species sessionid + instance id,
or you'll be using URL encodingand your direct action URL will have
both the instance ID as well as ?wosid=xxx in the URL (http://yoursite/cgi-bin/WebObjects/YourApp.woa/instanceid/daname?wosid=xxx
) ... should work fine
14 matches
Mail list logo
