Sto facendo programmazione di database usando Java con SQLite.
Ho scoperto che solo una connessione alla volta al database ha capacità di scrittura, mentre molte connessioni contemporaneamente hanno capacità di lettura.
Perché l'architettura di SQLite è stata progettata in questo modo? Finché le due cose che vengono scritte non vengono scritte nello stesso posto nel database, perché non possono verificarsi due scritture contemporaneamente?
Perché "più scritture simultanee" è molto, molto più difficile da realizzare nel motore di database principale rispetto al single-writer, a più lettori. È al di là dei parametri di progettazione di SQLite e includerlo potrebbe sovvertire le deliziose dimensioni e semplicità di SQLite.
Il supporto di elevati livelli di concorrenza di scrittura è un segno distintivo di motori di database di grandi dimensioni come DB2, Oracle, SQL Server, MySQL, PostgreSQL, NonStop SQL e Sybase. Ma è tecnicamente difficile da realizzare, richiede un controllo della concorrenza e strategie di ottimizzazione estese come il blocco di database, tabelle e righe o, in implementazioni più moderne, controllo della concorrenza multi-versione . La ricerca su questo problema / requisito è voluminosa e risale a decenni .
SQLite ha una filosofia di design molto diversa dalla maggior parte di quei DBMS server-centric che supportano più scrittori. È progettato per portare la potenza di SQL e il modello relazionale alle singole applicazioni e, in effetti, per essere integrato in ogni applicazione. Questo obiettivo richiede significativi compromessi. Non aggiungere l'infrastruttura significativa e il sovraccarico necessario per gestire più scrittori concorrenti è uno di quelli.
La filosofia può essere riassunta da una dichiarazione sulla usi appropriati della pagina:
SQLite does not compete with client/server databases. SQLite competes with fopen().
Perché non c'è un server che possa dire se le cose debbano essere scritte nello stesso posto oppure no. Ci sono solo due processi che tentano di scrivere su un file.
Come indicato in un commento, le scritture concorrenti potrebbero anche essere supportate da un thread interno. Non sono sicuro di come funzionerebbe (non ci ho pensato molto). Comunque, ecco perché SQLite non usa thread: Dr Hipp pensa che i thread siano malvagi.
Il fatto che DR Hipp pensi che i thread siano malvagi è documentato nelle Domande frequenti di SQLite .
Leggi altre domande sui tag database concurrency sqlite