Re: Your session has timed out. [SOLVED]
Re: Your session has timed out. [SOLVED]
- Subject: Re: Your session has timed out. [SOLVED]
- From: Jevon Hills <email@hidden>
- Date: Wed, 4 Jun 2003 16:52:58 -0600
Thanx to all of you who responded - My mail server went down so I could
not respond earlier to say that I had managed to solve this.
I had always taken the default install of WO never adjusted any of the
settings for any of my deployments. My requirements still aren't to
the level that I had needed to consider this(i.e. max 6 users, small
database, etc).
My problem was I didn't know what the default values for the adaptor
settings were and was leary of messing about with these perchance
causing more harm. However I took a chance and set my RECV timeout
longer, and my connection pool larger. This has relieved the issue as
it was just the report taking 31 - 33 seconds to run...
Thank you also for the other possibilities to relieve this as well. I
will take these and pursue them further in testing.
ttfn
Jevon
On Wednesday, June 4, 2003, at 03:04 PM, Jonathan Rochkind wrote:
At 01:08 PM 6/4/2003 -0700, Chuck Hill wrote:
requests which will block on the DB context lock. I think this would
only
be a problem when a call to saveChanges() took a long time.
Or any other EOF operation which is more or less 'atomic' to the
developer, which took a long time. For instance, I had an app which
needed to fetch a whole bunch of EOs, and the fetch took a long time.
I wanted to use WOLongResponse page here, but I couldn't figure out a
useful way to.
That would
lock the database context and all further DB access would block until
the
save completed. It should be OK for reporting where the app would
read a
bit of data (lock and unlock the DB context), process it, read a bit
more
etc. Or am I missing something?
Yes, good point. I actually hadn't thought of that, maybe because I've
never personally been in a situation where I wanted to use a long
response page for EOF operations where it would have been possible!
But in any situation where you can break your long computation up into
pieces, periodically releasing and re-taking your EOF locks, should
work better with a long response page. Long as your careful. But if
the operation is more 'atomic' as far as the developer's code is
concerned, and you can't (easily) periodically release and then
re-aquire the lock, you'll be blocking out your own 'status' page, as
well as potentially other users. That is the problem I've run into.
--Jonathan
Chuck
At 02:39 PM 04/06/2003 -0500, Jonathan Rochkind wrote:
>At 11:41 AM 6/4/2003 -0700, Chuck Hill wrote:
>
>>3. Use the WOLongResponsePage to generate the report. While this
is a
>>somewhat elegant and appropriate solution it also implicitly makes
your app
>>dispatch requests concurrently. This makes it very important that
your app
>>is threadsafe and all the EOF objects are getting locked properly.
You
>>will be wanting to test this!
>
>It's very tricky to get WOLongResponsePage to work when the
>long-running-computation involves EOF. With the newly better
documented
>EOF locking APIs, it should be possible somehow, but I haven't had
time to
>figure it out. You can't just do what seems obvious----because if
the long
>running computation has the right locks out on the EOF stack, then
the
>'update' page's request to see if the computation was done will end
up
>blocking until the computation IS done. Which usually isn't the
behavior
>you want, although if you don't need to show a 'progress bar', it
may be
>sufficient. But it can be tricky to get it working right. I wouldn't
>reccomend messing around with WOLongResponse for EOF operations
unless you
>have a reasonable idea of what's going on, and have some time to
figure it
>out.
>
>--Jonathan
>
>
>>4. Move the reporting to another reporting only application and
increase
>>the Connect and Receive timeouts. This will prevent the session
>>restoration errors while not blocking users of the main application.
>>
>>
>>Chuck
>>
>>--
>>
>>Chuck Hill email@hidden
>>Global Village Consulting Inc.
http://www.global-village.net
>>_______________________________________________
>>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.
>
>
--
Chuck Hill email@hidden
Global Village Consulting Inc.
http://www.global-village.net
Jevon K. Hills
Developer - Zymeta Media Promotion Systems
_______________________________________________
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.