Re: Your session has timed out.
Re: Your session has timed out.
- Subject: Re: Your session has timed out.
- From: Chuck Hill <email@hidden>
- Date: Wed, 04 Jun 2003 13:08:28 -0700
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) 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.