org.jgrasstools.dbs.spatialite.package-info Maven / Gradle / Ivy
/**
* Some comments about spatialite and multithreading
*
* (thanks to Sandro Furieri for this)
*
* When you launch multiple processes, each process
* has its own inviolable memory space on which no other process
* will be able to put its fingers on (apart of the old windows 95
* and 98, that had a memory management model that was a hybrid
* between a colander and a toilet bowl, but that is a different
* story).
*
* With threads instead the opposite applies. All threads
* that are children of the same process share a single memory space
* that they all own. Often that comes in handy, but in some cases
* it can be hell.
*
* Since SQLite does NOT work in client-server mode
* and you are working directly with the SQL engine, it is mandatory
* that every thread has its own very private memory space
* in order to avoid violation of the allocation/freeing mechanics
* by different threads, which would lead to either inconsistent
* results or segmentation faults.
*
*
Therefore:
*
* - using one db connection and many threads to interact in read-write
* mode is a configuration that HAS TO BE AVOIDED
* - if instead one connection for every thread is used, then one
* needs to make sure that one thread at the time connects
* to write, while multiple connections are allowed in read-only mode or
* else Exceptions will be raised due to the locking system.
*
* - the fact that all the connection threads come from the same process
* in this case doesn't matter. In SQLite one connection blocks the other
* and it is impossible to make multiple parallel writing operations.
* - multithreading for SQLite doesn't make any sense (at least not in
* terms of performance), since everything needs to be semaphorized, which
* results in a queued single thread model.
*
*
*
*
*/
package org.jgrasstools.dbs.spatialite;