Keeping an active cursor is *not* a problem. This is done all of the time. The cursor just holds an in-memory copy of a window on the result set. The only time it needs to look the database is when it is filling the window.
On the other hand, having a transaction open will keep the database locked until you close the transaction. Also it is SQLiteDatabase itself that implements the needed locking; ContentProvider doesn't do anything more here I believe. In fact ContentProvider relies heavily on the underlying locking of the database since its design executes incoming calls from other threads directly out of the local process's thread pool, so it is intrinsically multithreaded. You should never open a database multiple times. For example, if you have split your app into multiple processes, only one process should open the database. This is a case where you will really want to use a content provider even for only your own app's internal implementation, since the content provider owns the database and by design there will only ever be one instance of it running, in one process. (That said, if you *are* splitting your app into multiple processes, it is well worth asking why. It rarely is useful for an app to do this.) On Thu, Apr 7, 2011 at 4:17 AM, DanH <danhi...@ieee.org> wrote: > 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 <evgeny.n...@gmail.com> 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? > > > > On 2 апр, 01:51, DanH <danhi...@ieee.org> 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 <evgeny.n...@gmail.com> 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 <garyjamessi...@gmail.com> 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 <l...@bendlin.us> 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 > -- 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
