"Thread" Safety

[s.ross]

I'm not certain whether this applies to JazzRecord, but thought I'd
ask anyhow. I have a Ruby implementation that fetches from a Web
service kind of as follows:

- Thing 1: Get chunk of 100 master (small) records (1 Web service
call)
- Thing 2: For each of the 100 master records, get the detail and
insert into the database (1 Web service call per detail record)

In Ruby, I'm doing Thing 2 as separate threads and leaving the Thing 1
loop unblocked. It sped things up immensely. However, SQLite borks on
this occasionally because it doesn't manage concurrent access.

As JazzRecord, because of its intended platform, targets SQLite, does
this mean starting multiple detached event handlers or one-time timer
functions would suffer the same problem?

I haven't tried a Javascript implementation of parallel fetching but
thought I'd ask and see if anyone had tried such a thing first.

Thoughts?

[Chris Brown]

I would say this is more of a JavaScript issue than a JazzRecord one. Obviously JavaScript doesn't support multiple threads and having a process begin as the result of event callbacks won't change that,  which ever callback is triggered first will continue until complete then the next callback will run. There are a few ways around this is you have something that's going to do some very heavy computation which may cause the browser to become unresponsive:

- Move that process to a server script and communicate via an asynchronous XHR request
- Use the Google Gears worker pool (not very useful if you're not using gears)
- Put together an iframe hack, pass data in and out of an iframe, iframes have their own seperate thread (dirty hack)

Hope that helps.