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:04:09 -0500
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
_______________________________________________
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.