Connection pool has been unable to grant a connection to thread
Asked Answered
G

4

32

I'm using GreenDAO for database handling in Android. When performing many database changes (> 15.000) I get this error Message:

The connection pool for database '/data/data/...' has been unable to grant a connection to thread 312 (Thread-312) with flags 0x1 for 30.000002 seconds.

Everything gets stuck. Why does this error happen?

Gauldin answered 31/7, 2012 at 14:29 Comment(2)
Please provide more information on this issue. E.g. stack traces, does it occur on all tested devices?, Android versions tested, ...Bambi
I got the same problem. There are no stack trace, this same error repeatly appeared and I can no longer access the database. I wonder if somewhere in GreenDao there are open transaction but not end transaction in a finally clause.Acrefoot
P
12

I can't say for sure about this particular implementation, but there is a connectionpool usually backing a ORM. The connection pool opens a set number of connections to the database and recycles them as you close them and open new connections. What that error is telling you is that it probably hit a limit. That can happen for a large variety of reasons, one is that possibly there is some deadlock in the DB because you are updating two tables and two different transactions are holding different tables waiting for the other to release. Or simply that there are just too many open connections and the DB or connection pool just gets confused.

Sorry that is not really an answer, but you are going to need to look at the docs for GreenDAO to see how this might happen.

Putman answered 31/7, 2012 at 16:28 Comment(1)
greenDAO does not use any connection pools itself. Apps with greenDAO behave just like many Android apps using SQLite. You get an SQLiteDatabase using some sort of SQLiteOpenHelper. Instances of DaoMaster/DaoSession refer to this SQLiteDatabase object.Bambi
D
36

I got this message when I want to select a query on a table which is used on a transaction without ended transaction before. Problem solved after executing endTransaction() on finally block of transaction.

Dinosaurian answered 26/12, 2012 at 16:12 Comment(1)
Also think about making batches when importing large datasets. Say, make endTransaction() and start a new transaction after n entities.Shoveler
P
12

I can't say for sure about this particular implementation, but there is a connectionpool usually backing a ORM. The connection pool opens a set number of connections to the database and recycles them as you close them and open new connections. What that error is telling you is that it probably hit a limit. That can happen for a large variety of reasons, one is that possibly there is some deadlock in the DB because you are updating two tables and two different transactions are holding different tables waiting for the other to release. Or simply that there are just too many open connections and the DB or connection pool just gets confused.

Sorry that is not really an answer, but you are going to need to look at the docs for GreenDAO to see how this might happen.

Putman answered 31/7, 2012 at 16:28 Comment(1)
greenDAO does not use any connection pools itself. Apps with greenDAO behave just like many Android apps using SQLite. You get an SQLiteDatabase using some sort of SQLiteOpenHelper. Instances of DaoMaster/DaoSession refer to this SQLiteDatabase object.Bambi
A
0

I got this message when creating too many connections to SQLite via DBFlow FlowQueryList . My solution was to make sure that once you were done with the query list to call endTransactionAndNotify() and then close() on the querylist.

Calling endTransactionAndNotify() alone did not do the trick. I hope this helps, this thread certainly helped me.

Antipersonnel answered 27/9, 2016 at 20:12 Comment(0)
R
0

Encountered a similar scenario described above however it was purely based on the queries themselves and not the APIs called. It happened when a view mistakenly overrode a table name (honest mistake) which sent the database and all the worker threads into a some kind of deadlock. The view doesn't return the anticipated table structure. Unclear why an error wasn't thrown and program fails, but instead this stuck state.

12-19 19:39:28.819 14644 17079 W SQLiteConnectionPool: Connections: 1 active, 0 idle, 0 available.
12-19 19:39:28.819 14644 17079 W SQLiteConnectionPool:
12-19 19:39:28.819 14644 17079 W SQLiteConnectionPool: Requests in progress:
12-19 19:39:28.819 14644 17079 W SQLiteConnectionPool:   executeForCursorWindow started 1056586ms ago - running, sql="select * from some_table", tid=15209
12-19 19:39:29.531 14644 17040 W SQLiteConnectionPool: The connection pool for database '/data/user/0/com.google.app/databases/234827384.db' has been unable to grant a connection to thread 549 (ExecutorFactory$1) with flags 0x1 for 51.018 seconds.
12-19 19:39:29.531 14644 17040 W SQLiteConnectionPool: Connections: 1 active, 0 idle, 0 available.
12-19 19:39:29.531 14644 17040 W SQLiteConnectionPool:
12-19 19:39:29.531 14644 17040 W SQLiteConnectionPool: Requests in progress:
12-19 19:39:29.531 14644 17040 W SQLiteConnectionPool:   executeForCursorWindow started 1057297ms ago - running, sql="select * from some_table", tid=15209
12-19 19:39:29.585 14644 17056 W SQLiteConnectionPool: The connection pool for database '/data/user/0/com.google.app/databases/234827384.db' has been unable to grant a connection to thread 562 (ExecutorFactory$1) with flags 0x1 for 51.018 seconds.
12-19 19:39:29.585 14644 17056 W SQLiteConnectionPool: Connections: 1 active, 0 idle, 0 available.
12-19 19:39:29.585 14644 17056 W SQLiteConnectionPool:
12-19 19:39:29.585 14644 17056 W SQLiteConnectionPool: Requests in progress:
12-19 19:39:29.585 14644 17056 W SQLiteConnectionPool:   executeForCursorWindow started 1057351ms ago - running, sql="select * from some_table", tid=15209
12-19 19:39:29.832 14644 14736 W SQLiteConnectionPool: The connection pool for database '/data/user/0/com.google.app/databases/234827384.db' has been unable to grant a connection to thread 100 (DefaultDispatcher-worker-1) with flags 0x1 for 42.014004 seconds.

Hope this helps anyone out there because it's a tough scenario to debug.

Refection answered 19/12, 2023 at 23:51 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.