0

I am currently developing an android application for my project.

My project aim to have a multiple countdown timer(not more than 50) running on a background using a Handler post delayed. On every seconds, I have to query into my table to fecth and update some specific column.

my query is wrap with a try catch and I am closing the Database at finally. This approach is working properly with a single thread, but once it become more than one threads, it gives me an error something like the database is already close but morethan one thread is trying to access it.

So I came up with idea to not close the database unless the whole application is closed.

So my question is, should I do what I am thinking? or there is a better approach for this?

Polar
  • 3,327
  • 4
  • 42
  • 77
  • you are closing the DB somewhere. Double check the code you copy-pasted – Chisko Nov 19 '16 at 08:40
  • 1
    Try this way: http://stackoverflow.com/questions/35358186/best-way-to-access-database-in-multi-threaded-application-android – Farshad Khodamoradi Nov 19 '16 at 08:43
  • @Chisko - I'm sorry if I made you some misunderstand about my question, please read the question clearly. I said `I am closing the database at finally`(I know what I am doing and where I am closing the database and I also know where the error/problem is), and since it is accessing by multiple threads it will give an error. Please read also `the last Line` I wrote. – Polar Nov 19 '16 at 08:43
  • In that case, you are not providing enough background of what you are trying to accomplish. Why do you close the DB if other threads are going to use it? What is not clear about creating a thread and accessing a resource beyond a try catch block? – Chisko Nov 19 '16 at 08:47
  • 1
    Can you post your code rather than we assuming many things ? – Vasu Nov 19 '16 at 08:59
  • @Chisko - That's why I am asking the question. A number of thread running a countdown timer will be created base on user. I do want to close the database after the operation as a good practice because not all the time there will be a thread running on the background who will access it. That's why I am asking if `I should do what I am thinking` or `There is a better approach`. – Polar Nov 19 '16 at 09:02
  • I don't think you are attacking the problem on a right manner. Of course closing the DB is good, but you do it when you won't need it! Check @javaguy advice please – Chisko Nov 19 '16 at 09:04
  • @Polar you could always maintain a counter, incremented when a thread is started, decremented when complete and then only close when the counter hits 0 and then only open when it is 0. – MikeT Nov 19 '16 at 09:05
  • @Polar I never meant to rant either one of you. It's just that this question seems to be outsmarting the system and you are not providing a solid justification for it nor demonstrating that you posses the knowledge or experience to do it, so my opinion is that you have no idea of what you are asking, nor that you are correctly trained in the system you are trying to develop on. I will always be against bad software, so pardon me if I burst into flames. – Chisko Nov 25 '16 at 04:17

1 Answers1

0

From the official docs:

SQLiteOpenHelper (Context context, 
                String name, 
                SQLiteDatabase.CursorFactory factory, 
                int version)

Create a helper object to create, open, and/or manage a database. This method always returns very quickly. The database is not actually created or opened until one of getWritableDatabase() or getReadableDatabase() is called.

And:

void close ()

Close any open database object.

So as you might appreciate, getting an instance of your SQLiteOpenHelper is not the same as having an object with access to the database. You need to manage your singleton instance accross all threads you want to create as well as your calls to getWritableDatabase() or getReadableDatabase() respectfully.

EDIT

Moreover, it's also stated in the Official SQLite Documentation that in order to be used in multithreading application there is additional setup to be done. I don't think I have to say Android is not designed to be a multithreading environment, see this answer please. Why do you push the barriers? Stick too good practices. Do further research. Google first.

Community
  • 1
  • 1
Chisko
  • 3,092
  • 6
  • 27
  • 45