[android-developers] Re: Android sqlite and multithreading
Hi everybody again!
So, advices here helped! Thanks!
After some research and testing this solutions seem to work OK:
I have only one!! writable sqlite db. (implemented using singleton as
some people suggested here)
Also, I've got some db code to synchronize write operations.
Only one thread can execute write transaction at one time. But I don't
care about opening Cursors and reading from them.
This solution works perfectly after some testing.
On 8 апр, 02:15, Dianne Hackborn wrote:
> On Thu, Apr 7, 2011 at 2:04 PM, Nathan wrote:
> > "The database"? I guess that would work if you only use ONE,
> > statically determined database.
> > Since I don't have just one, I think I need a singleton hash table of
> > opened databases, like I mentioned.
>
> You are making this too complicated.
>
> class StuffDatabase {
> SQLiteDatabase mDatabase;
> static StuffDatabase getInstance();
>
> }
>
> class OtherStuffDatabase {
> SQLiteDatabase mDatabase;
> static OtherStuffDatabase getInstance();
>
> }
> > I'll take your word for it. So if the user opens 10 or 100 databases
> > in a session, I'll just leave them all open. That simplifies the
> > singleton implementation if I don't have to do reference counting.
>
> Why in the world do you have 10s of databases?
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails. All such
> questions should be posted on public forums, where I and others can see and
> answer them.
--
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
[android-developers] Re: Android sqlite and multithreading
Kostya, how many users do use your app? Cause my version works ok for me and for most my users. But some of them keep getting such error. I think, this problem is related to some devices, not every. Or, may be some very specific cases. Also, do your background threads use ContentProvider to insert/update data? Or just interface? DanH, I don't get this exception every time (as Kostya said too), so it's ok keeping Cursor open And, I'll try to do this with ContentProviders ) On 7 апр, 15:41, Kostya Vasilyev wrote: > That's not what I'm seeing with my current project. > > My UI code uses a LiveView with a CursorAdapter, and has background > threads that access and write to the database, sometimes using > transactions, sometimes not. > > I've never seen a "database locked" exception, even when triggering a > background thread to do its thing while I have a cursor-based ListView > on the screen. > > One possible difference is that my ListView gets its cursor through a > ContentProvider. > > Another possible difference is that my UI code and worker threads are > all within the same process, and they all use the same SQLiteDatabase > object, so the DB is only open once. > > -- Kostya > > 07.04.2011 15:17, DanH пишет: > > > > > > > > > > > The problem is that when you "hold the cursor open" the database is > > locked. That feature is not really applicable to a multi-threaded SQL > > environment. > > > On Apr 7, 1:01 am, Evgeny Nacu wrote: > >> > Hi again! > > >> > DanH, I use thread synchronization. It works well. > >> > But, as I told in my first post, there are some problems: > > >> > The biggest problem: I can't use Cursor for my ListAdapter and > >> > ExpandableListAdapter > >> > I've got to use something like ArrayAdapter, read all data from cursor > >> > to java objects at one time. > > >> > But, as I understand, CursorAdapter works better cause it can hold > >> > cursor open and scroll through cursor and read data when needed > >> > It works faster for me. > > >> > So, also, here is new exception I've got today. > >> > I retried to implement UI handling with Cursor. And I've got > >> > SQLiteException: database is locked: BEGIN EXCLUSIVE; > > >> > Who knows how to handle it? > > -- > Kostya Vasilyev --http://kmansoft.wordpress.com -- 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
[android-developers] Re: Android sqlite and multithreading
Hi again! DanH, I use thread synchronization. It works well. But, as I told in my first post, there are some problems: The biggest problem: I can't use Cursor for my ListAdapter and ExpandableListAdapter I've got to use something like ArrayAdapter, read all data from cursor to java objects at one time. But, as I understand, CursorAdapter works better cause it can hold cursor open and scroll through cursor and read data when needed It works faster for me. So, also, here is new exception I've got today. I retried to implement UI handling with Cursor. And I've got SQLiteException: database is locked: BEGIN EXCLUSIVE; Who knows how to handle it? On 2 апр, 01:51, DanH wrote: > A content provider won't provide any function over what you have now > -- it's just a different way to accomplish the same synchronization. > WithSQLiteyou basically can't have two transactions going on at the > same time, so you must either use semaphores or some such to prevent > "collisions" or use a server (content provider) so that all the > accesses are through a single thread. > > If you understand threads and thread synchronization/exclusion then > your way is probably more efficient and just as reliable. If you > don't understand threads then the content provider technique is safer. > > On Apr 1, 7:51 am, Evgeny Nacu wrote: > > > > > > > > > Thanks to everyone! > > I've heard that ContentProviders do not have such problem. May be > > I'll try to use them, but I have many things to change. > > Thanks for the suggestion. > > > Evgeny > > > On 1 апр, 05:11, gjs wrote: > > > > Hi, > > > > I (strongly?) suggest you wrap access to the sqlite3 database in a > > > Content Provider if you are accessing concurrently (doing both > > > read&write) from Activity & Service - particularly if Service is in > > > different process. > > > > Content Provider seems to manage concurrent access for you ok, without > > > having to get involved with semaphores/synchronization yourself. > > > > Regards > > > > On Apr 1, 9:21 am, lbendlin wrote: > > > > > yes, semaphores are the way to go, especially for bulk write > > > > operations. it > > > > helps if you read some of the data from the database into a buffer. > > > > Then you > > > > can use the buffered data while the database update is processed, and > > > > the > > > > users may not even notice. -- 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
[android-developers] Re: Android sqlite and multithreading
Thanks to everyone! I've heard that ContentProviders do not have such problem. May be I'll try to use them, but I have many things to change. Thanks for the suggestion. Evgeny On 1 апр, 05:11, gjs wrote: > Hi, > > I (strongly?) suggest you wrap access to the sqlite3 database in a > Content Provider if you are accessing concurrently (doing both > read&write) from Activity & Service - particularly if Service is in > different process. > > Content Provider seems to manage concurrent access for you ok, without > having to get involved with semaphores/synchronization yourself. > > Regards > > On Apr 1, 9:21 am, lbendlin wrote: > > > > > > > > > yes, semaphores are the way to go, especially for bulk write operations. it > > helps if you read some of the data from the database into a buffer. Then you > > can use the buffered data while the database update is processed, and the > > users may not even notice. -- 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
[android-developers] Android sqlite and multithreading
Hi everybody! I would like to know better ways to use SQLite in Android. I've got some UI Activities and background service (Android service which runs some AsyncTasks to change the data, they also can use database concurrently ) First I tried to use all this stuff as is, just open cursor in ListActivity, show data. My AsyncTasks were doing some changes to my local sqlite db. So, sometimes I was getting: DATABASE IS LOCKED exception. Then I tried to synchronize all my update/insert/delete parts of my AsyncTasks. So my app got better, almost everything was working wonderfull. But, some users were sending error messages with all the same exception. So, I finished with such solution for now: I do not hold any Cursors open. I open it, read to my arraylists, then close. So I also tried to synchronize read methods. Now everything is working fine, no "DATABASE IS LOCKED" exception. But, I don't like such solution, first of all because of performance issues. Opening cursor and getting all data from it to arraylist is not very cool and fast. May be I missed something?! How do you use sqlite in Android? -- 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
