Re: Your session has timed out.
Re: Your session has timed out.
- Subject: Re: Your session has timed out.
- From: Jonathan Rochkind <email@hidden>
- Date: Wed, 04 Jun 2003 16:07:24 -0500
At 01:08 PM 6/4/2003 -0700, Chuck Hill wrote:
Yes, that is a problem. Not so much for the update on the LR page (which
can just check a flag set by the thread with the EOF lock)
PS: How can the status page check this flag? Ordinarily, it will do so
with a request to the server. Ordinarily, a session-based request to the
server automatically takes out a lock on
session.defaultEditingContext(). If it can't acquire this lock becuase of
work going on in the long computation.... then the request going to block
until the long computation is done. If you want to give the user a
progress bar, that's not going to work. If you just want to give the user
a non-changing 'please wait' message until the computation is complete, it
may work---unless the browser (or the web server!) times out the request
before the computation is complete!
Am I missing something?
--Jonathan
but for other
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. 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?
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
_______________________________________________
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.
_______________________________________________
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.