Async Issue with DB Calls

> -----Original Message-----
> From: Ron Teitelbaum
> Sent: Monday, November 13, 2006 4:10 PM
>
> Hello all,
>
> I had an interesting problem.  I'm wondering what the impact is to using
> async updates during non blocking calls.
>
> I wrote a zipcode look up.  It works fine after the first time but when
> you
> start up the image the first time it breaks.
>
> What is happening is that I get the response back but the entire page
> except
> for the update shows up.
>
> In my case it's the city and state fields that show up but nothing else.
> So
> what I get is when you type in a zip code the page disappears and only the
> two returned fields show up.
>
> Since it works after the first time I figured it must have something to do
> with the database call and the logon, so I shut down the image, started it
> back up and ran the query.  There is a bit of a delay the first time but
> it
> does work.
>
> My guess was that it was a problem with blocking, so I added a semaphore
> to
> make sure that seaside didn't return with the async while squeak called
> out
> to the db.
>
> html tableRow with: [
> html tableData with: [html text: 'Zip: '].
> html tableData with: [
> html textInput on: #zip of: self address; size: 50;
> liveCallback: [:event :h |
> self class accessSemaphore critical: [
> aZip := ZipCodes selectForZipCode:
> event.
> ].
> aZip ifNotNil: [
> self address city: aZip city.
> self address state: aZip state.
> ].
> h tableData id: #city; with: [h textInput
> on: #city of: self address; size: 50].
> h tableData id: #state; with: [h textInput
> on: #state of: self address; size: 50].
> ]
> ].
> ].
>
> This worked and solved my problem.  So my questions are.  How sensitive is
> async to the system returning?  Do I need to have a blocking call for all
> external calls within async?  Any idea why it works the second time
> without
> the semaphore?  Is there some time limit or something that I've missed
> that
> causes async to return even though squeak is still processing the
> callback?
>
> Thanks for your help!
>
> Ron Teitelbaum
> President / Principal Software Engineer
> US Medical Record Specialists
> [hidden email]
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> It appears that I was wrong.  The semaphore didn't fix things.
>
> It appears that when I'm sending the first call after the image is started
> that the live update can be triggered more then once, while other updates
> are synchronous.  In my case if I enter the zip code numbers one at a time
> it appears to work, but if I put in multiples after starting the image I
> have a problem.  The first call doesn't have a response; the
> response.responseText is Unknown on IE and null on FireFox.
>
> I tried removing the semaphore and adding:
>
> if (request.readyState == 4 && request.responseText == "OK")
>
> This appears to have fixed the problem.  I thought it was fixed earlier so
> more testing will tell.
>
> It appears that the first response with no response may be clearing the page
> and the second response is writing out values.
>
> Any thoughts on what's going on?

> > -----Original Message-----
> > From: Ron Teitelbaum
> > Sent: Monday, November 13, 2006 4:10 PM
> >
> > Hello all,
> >
> > I had an interesting problem.  I'm wondering what the impact is to using
> > async updates during non blocking calls.
> >
> > I wrote a zipcode look up.  It works fine after the first time but when
> > you
> > start up the image the first time it breaks.
> >
> > What is happening is that I get the response back but the entire page
> > except
> > for the update shows up.
> >
> > In my case it's the city and state fields that show up but nothing else.
> > So
> > what I get is when you type in a zip code the page disappears and only the
> > two returned fields show up.
> >
> > Since it works after the first time I figured it must have something to do
> > with the database call and the logon, so I shut down the image, started it
> > back up and ran the query.  There is a bit of a delay the first time but
> > it
> > does work.
> >
> > My guess was that it was a problem with blocking, so I added a semaphore
> > to
> > make sure that seaside didn't return with the async while squeak called
> > out
> > to the db.
> >
> > html tableRow with: [
> >       html tableData with: [html text: 'Zip: '].
> >       html tableData with: [
> >               html textInput on: #zip of: self address; size: 50;
> >                       liveCallback: [:event :h |
> >                               self class accessSemaphore critical: [
> >                                       aZip := ZipCodes selectForZipCode:
> > event.
> >                               ].
> >                               aZip ifNotNil: [
> >                                       self address city: aZip city.
> >                                       self address state: aZip state.
> >                               ].
> >                               h tableData id: #city; with: [h textInput
> > on: #city of: self address; size: 50].
> >                               h tableData id: #state; with: [h textInput
> > on: #state of: self address; size: 50].
> >                       ]
> >               ].
> >       ].
> >
> > This worked and solved my problem.  So my questions are.  How sensitive is
> > async to the system returning?  Do I need to have a blocking call for all
> > external calls within async?  Any idea why it works the second time
> > without
> > the semaphore?  Is there some time limit or something that I've missed
> > that
> > causes async to return even though squeak is still processing the
> > callback?
> >
> > Thanks for your help!
> >
> > Ron Teitelbaum
> > President / Principal Software Engineer
> > US Medical Record Specialists
> > [hidden email]
> >
> > _______________________________________________
> > Seaside mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

>
> > I don't know if this is related but I observed and reported the
> > following (only on SeasideAsync, not on Scriptaculous):
> > If an async call is made before a previous async call returns this
> > screws up FireFox, basically it just displays and empty white page.
> > You have to reload the page. For some reason this isn't an issue on
> > Opera and Safari.
> >
> > I haven't heard from any progres with this issue.
> >
>
> This issue has been addressed in SeasideAsync-mb.53.
> The symptom did not re-occur in the initial tests.

> -----Original Message-----
> From: Michel Bany
> Sent: Friday, November 17, 2006 4:31 AM
>
>
> > I don't know if this is related but I observed and reported the
> > following (only on SeasideAsync, not on Scriptaculous):
> > If an async call is made before a previous async call returns this
> > screws up FireFox, basically it just displays and empty white page.
> > You have to reload the page. For some reason this isn't an issue on
> > Opera and Safari.
> >
> > I haven't heard from any progres with this issue.
> >
>
> This issue has been addressed in SeasideAsync-mb.53.
> The symptom did not re-occur in the initial tests.
>
> Enjoy,
> Michel.
>
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside