Dealing with excess queueing

[brodycj]

In a batch transaction the SQL operations are queued until tx.commit() or tx.abort() is called. If there are too many SQL operations there is a risk that the commit stage may be too slow or the app could run out of memory resources, especially on older devices. I can think of the following alternative ways to deal with this issue:

• Automatically split the batch into chunks and commit these chunks along the way. Disadvantage: this would no longer be atomic.
• Adapt the cordova-sqlite-evplus-ext-free JavaScript to support the multi-part transaction mechanism like I did in the evplus-legacy versions. Disadvantage: it would not be possible to support this in the browser platform without a more drastic solution such as using SQL.js.
• Find a way to fix or replace Oboe.js so that we can populate the database all at once following the Web SQL API

[holger-schif]

Just to understand how the plugin works: do you have to send the whole statements for one transaction at once "to your native code"? Or is something possbile like this:

• Open transaction
• Collect MAX_CHUNK_SIZE statements in the JavaScript-side
• "Send" it to the native code and "free" the memory in JavaScript
• And so on
• Finally commit or rollback the transaction (or rollback the transaction, as soon as an error occured)
  Or am I on the "wrong track", because it's not possible or not a good idea (for whatever reason)?

For us, at the moment, your second suggestion would be the best solution. I do not think we will need the browser support in the near future. But I think we can also live with the first solution (commit the batch in chunks) and find a solution to ensure consistency of the data (I think this will be possible to do for us on the server side)