SQLite Zugriffsproblem

Das Geheimnis ist der Isolation Level. Mit SQLite habe ich das noch nicht benötigt aber schau Dir mal den Shared Cache an.

Ansonsten müßte man mal über das Design nachdenken. Ich mache etwas Ähnliches gehe aber anders vor.

Das was Du beschrieben hast wird so nicht ganz funktionieren. Ich war gestern nur mit meinem kleinen Handy unterwegs deshalb war die Antwort relativ kurz.

* Einfügen der Koordinaten: Kein Problem. Die werden von Dir, hoffentlich mittels PreparedStatements, gegen die DB gefeuert damit es sehr schnell geht. Sie nehmen sich einen exklusiven Lock und hängen die Daten rein (Index, Daten). Kann mit allem parallel laufen.

* Löschen von Koordinaten: Dto. wird halt nur gelöscht.

* Lesen von Koordinaten: Nur ein kleines Problem. Im Standard Isolation Level werden nur Daten gelesen die commitet sind. Das würde ich auch so lassen. Allerdings würde ich in Chunks (zur Übertragung und Löschung) lesen und diesen Cursor immer schließen. SQLite hat meines Wissens keine "WHERE CURRENT OF--cursor-name" Klausel - was auch mit einer zwischengeschalteten Netzwerk-Kommunikation sehr unglücklich wäre. Deshalb würde ich mir immer einen Block holen, einzeln übers Netz schicken und Zug um Zug löschen. Danach Cursor wieder auf etc. EDIT: Oder requery() ausführen damit der Cursor die neuen Daten mitbekommt.

* Eintragen neuer Nachrichten: Kein Problem, siehe Einfügen der Koordinaten

* Lesen der Nachrichten: Hier kommt ein etwas größeres Problem - ist aber machbar. Ein Cursor ist ja ein Resultset - eine Sicht auf die Daten zu einem bestimmten Zeitpunkt. Nun fließen aber parallel weitere Nachrichten rein. Der Standard CursorAdapter bekommt das nicht mit - Du musst bei diesem immer CursorAdapter.notifyDataSetChanged() oder Cursor.requery() ausführen. Damit veranlasst Du eine Aktualisierung. Neuere CursorLoader bringen von Hause aus Observer mit. Damit müsste es gehen. Leider gibt es die erst ab API11 sie sind aber Bestandteil der Support-Library.

* Zentrale Instanz: Ich arbeite ausschließlich so. Das ist auch ausdrücklich "nicht untersagt" ;-) In den Code Snippets zwei Bretter weiter findest Du dazu von mir einen Beitrag. Ich nutze immer eine Subclass von Application. Ob das da drin statisch sein muss "MyApplication.getSqliteOpenHelper.deleteIrgendwas(1)" oder ob Du Singletons nimmst ist Dir überlassen. Parallele Aktivitäten sind kein Problem für Datenbanksysteme. Wenn die das nicht können dann haben die ihre Daseinsberechtigung verloren.

— geändert am 11.09.2012, 16:15:46

Auf alles ein Ja außer auf das Stören. Instanzen stören sich nicht.

Vergiss getReadableDatabase - der Code ist fast identisch mit getWritableDatabase - das erste ist nur ein Fallback.

Ich denke alles andere ist gesagt.

10ms? Was soll das? Bekommst Du alle 10ms einen Koordinaten-Update?

Denk nicht drüber nach. Konzentriere Dich auf Deine App und wie Du das Szenario sauber implementierst. Dann hast Du keine Probleme mit der Datenbank.

Ein Lock in dem Sinne wie Du den vermutlich interpretierst gibt es nicht. Datenbanken locken z.B. Rows bzw. Tabellen für exklusive Zugriffe wie z.B. einen INSERT. Wenn nun parallel ein weiterer exklusiver Zugriff auf diese Row erfolgt (z.B. ein DELETE) dann entsteht ein Deadlock. Aber selbst diese sind auf Deiner Ebene unproblematisch da Datenbanksysteme dafür eine Lock-Eskalations-Strategie nutzen. Einem der beiden Zugriffe wird dann Vorrang gegeben und der andere läuft dann in den Rollback. Wenn Du also während des INSERTs direkt den DELETE auf die selbe Row machst dann bekommst Du exakt diese Situation. Auch in extrem kurzen SELECT Situationen im Shared-Zugriff kann das passieren. Das ist bei Deinem völlig irren 10ms Test nicht auszuschließen. Um das zu umgehen musst Du halt auf Dirty-Read (Uncommited Read) umstellen.

Das sind DBA Dinge. Wenn Du das für eine App benötigst dann wird die App das System in die Knie zwingen und somit das Device überbeanspruchen.

Nicht ganz.

Der Fetch, also der Cursor, ist ein Blick auf die Daten zu einem Zeitpunkt X. Je nach Isolation Level "sieht" dieser Cursor unter Umständen unterschiedliche Daten (commited, uncommited).

Das Lesen des Cursors erzwingt einen Shared Lock - und zwar mit jeder Row die Du "besuchst". Parallele exklusive Zugriffe auf andere Tabellen funktionieren nur in den Pausen. Diese exklusiven Zugriffe werden aber erst commited wenn der Cursor geschlossen ist. Insofern ist der Cursor ein kritischer Punkt - auch wenn er nur liest. Das meinte ich in einem der Posts zuvor als ich anregte das Du den Cursor in Chunks liest und wieder schließt. Diese Locking-Strategien von SQLite kannst Du hier nachlesen. Sie unterschieden sich teilweise gravierend von anderen Datenbanksystemen.

Hier merkt man eine der vielen Schwächen von SQLite. Man kann aber uch nicht erwarten das eine 300KB SQLite-Engine das selbe leistet wie z.B. eine IBM DB2 Engine.

— geändert am 12.09.2012, 11:40:37