Cordova SQLite redesign - native access hurdles

[brody4hire]

I have a customer who is interested in the new Cordova SQLite plugin design discussed in #3, with additional access possible from a custom native plugin, but we are facing a couple of hurdles at this point:

1. Using multiple connections to the same database is known to cause blocking between writer and one or more readers. (No blocking issues expected in case of multiple readers with no writers.) This seems to be an issue on both Android and iOS.
2. They are using a custom build of "sqlite-android" (similar to https://sqlite.org/android and https://github.com/requery/sqlite-android) with built-in support for R-Tree and some other custom features. Using that kind of a library on Android is not yet supported by the prototype I made for Starting new SQLite plugin design for Apache Cordova #3.

[brody4hire]

Ideas for Hurdle 1

I think the easiest solution for hurdle 1 (reader/writer blocking) would be to switch to using WAL mode, which I have started to evaluate in #7. I think the major disadvantage would be in the automatic or manual checkpointing that would likely be needed from time to time.

The alternative would be to implement some kind of transaction queueing for both Cordova JavaScript and custom native access, with some kind of a new asynchronous API likely needed for the custom native plugin. In case this kind of transaction queueing is needed, I would like to do this in one or more higher-level components outside of the redesigned plugin.

Ideas for Hurdle 2

I would need to evaluate how it would be possible to have both the new Cordova plugin and some form of "sqlite-android" share the same SQLite build. I would likely need several days to evaluate this kind of an idea. I would like to keep the higher-level "sqlite-android" library in a separate component, if possible.