[Seaside] Async Issue with DB Calls

[Ron Teitelbaum]

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?

Ron Teitelbaum



> -----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
> Ron at USMedRec.com
> 
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside