Just another related thought: SQLiteDatabase contains some implicit "transaction magic" under the hood which is meant to prevent "accidents" due to simultaneous accesses from different threads. That does not always work that great and can lead to some kind of indefinite deadlock situation. You can ease that problem by making sure to only give one thread "ownership" of the db connection by letting it open and query the connection.
You also must make sure not to open the same database connection multiple times. In older Android versions that error was not treated gracefully and the database file could get corrupted. In newer versions you are greeted with an exception. When the database file gets corrupted, the default behavior of SQLiteDatabase is "silently" dropping the whole database file and creating a new one, so basically you start from scratch in such a situation and probably your table creation / setup routines kick in and start fresh. On Wednesday, July 31, 2013 2:01:33 PM UTC-5, Nathan wrote: > > > > On Wednesday, July 31, 2013 9:21:59 AM UTC-7, Nobu Games wrote: >> >> How are you handling transactions in your queries? > > > A single record written is done as a single transaction. I believe, > though, that the writing part is all done and it is now just reading. No > transactions on reading. > > > >> In later versions of Android SQLite writes by default temporary >> "journaling" data files that are not immediately merged with the actual >> database file (see here: http://www.sqlite.org/tempfiles.html). This >> might be an explanation for the reported behavior, see the following quote >> from the SQLite documentation: >> >> However, if the last connection does not shutdown cleanly, the WAL file >>> will remain in the filesystem and will be automatically cleaned up the next >>> time the database is opened. >>> >> > I would expect some blocking on first open after a crash in that > situation. > > >> Other than that, are you sure the path argument is always the same? >> > > Not completely sure. I want to investigate if there is a possibility of > getting two paths that are equivalent, yet don't look the same in a string > compare. > If so, this code would fail to prevent opening the same file twice in the > same process. > > Nathan > > -- -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
