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 14:36:12 -0700
I've never used session.defaultEditingContext() in the thread processing
the long request. Seemed like a bad idea. Hence the next request does not
block. Locking the EC doesn't (last time I checked) lock the DB Context.
Multiple treads can lock multiple ECs at the same time. They just can't
lock the same one.
Chuck
At 04:07 PM 04/06/2003 -0500, Jonathan Rochkind wrote:
>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.
>
--
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.