i don't see there any changes to event_handlers.py or packet_processor.py, they could be missed
https://github.com/chrisdavis2110/remote-terminal-meshcore/commit/cde4d1744e5448baa11d0f5ee90fedf5b91c9633
i don't see there any changes to event_handlers.py or packet_processor.py, they could be missed
<!-- github-comment-id:4251471444 -->
Okay I've pushed another commit that is a bit more meaningful of a change; moving all our DB traffic to a more context/locky method. TBH I'm not sure exactly what the problem here is -- of course, a DB concurrency issue, but I've had my brain and a bunch of agents scrambling over the codebase to try and repro this failure and I can't even do it in a contrived way, thus I cannot confirm my fix. Hopefully this does it; if not, I'll come back around for a more aggressive whack.
Okay I've pushed another commit that is a bit more meaningful of a change; moving all our DB traffic to a more context/locky method. TBH I'm not sure exactly what the problem here is -- of course, a DB concurrency issue, but I've had my brain and a bunch of agents scrambling over the codebase to try and repro this failure and I can't even do it in a contrived way, thus I cannot confirm my fix. Hopefully this does it; if not, I'll come back around for a more aggressive whack.
<!-- github-comment-id:4264537007 -->
=> it happens when a commit is executed while here are unfetched return values.
Here's an interesting possible cause for that exact error ("cannot commit transaction - SQL statements in progress"):
https://stackoverflow.com/questions/1049293/sqlite-error-cannot-commit-transaction-sql-statements-in-progress-using-java
=> it happens when a commit is executed while here are unfetched return values.
<!-- github-comment-id:4266206499 -->
Yes, the issue is definitely around in-flight data fetching; I just wasn't able to force the codebase into a reproduceable flow [that I had any confidence in actually being the root of the problem]. The fix I pushed should hopefully be the solution with some bigger-picture transaction isolation.
Yes, the issue is definitely around in-flight data fetching; I just wasn't able to force the codebase into a reproduceable flow [that I had any confidence in actually being the root of the problem]. The fix I pushed should hopefully be the solution with some bigger-picture transaction isolation.
<!-- github-comment-id:4266233079 -->
I just found it interesting that this issue is not only an issue of concurrent read access vs. write access but may also be related to unfetched return values from e.g. an INSERT statement that includes RETURNING.
But despite SQLITE3 having a bunch of locking mechanisms (like read locks that can be upgraded to write locks, see https://www.sqlite.org/lockingv3.html) - I've not yet digged into the python API to check how they leverage locking.
Fingers crossed.
I just found it interesting that this issue is not only an issue of concurrent read access vs. write access but may also be related to unfetched return values from e.g. an INSERT statement that includes RETURNING.
But despite SQLITE3 having a bunch of locking mechanisms (like read locks that can be upgraded to write locks, see https://www.sqlite.org/lockingv3.html) - I've not yet digged into the python API to check how they leverage locking.
<!-- github-comment-id:4266300090 -->
But maybe this will be handy - a lightweight SqliteWorker library that streamlines all DB access into a threadsafe queue with only a single dedicated worker thread doing all DB access:
But maybe this will be handy - a lightweight SqliteWorker library that streamlines all DB access into a threadsafe queue with only a single dedicated worker thread doing all DB access:
https://medium.com/@roshanlamichhane/sqlite-worker-supercharge-your-sqlite-performance-in-multi-threaded-python-applications-01e2e43cc406
<!-- github-comment-id:4266314652 -->
Yeahhhh the whole time I was troubleshooting this I kept waffling on just cutting over to a connection pooler or some other more meaningful kind of sequence control that's less miserable to operate on.
Yeahhhh the whole time I was troubleshooting this I kept waffling on just cutting over to a connection pooler or some other more meaningful kind of sequence control that's less miserable to operate on.
<!-- github-comment-id:4266324416 -->
I've not yet digged into the python API to check how they leverage locking
Basically not, from what I understand of sqlite. There are not any batteries included for this kind of thing beyond help from other libraries afaik.
> I've not yet digged into the python API to check how they leverage locking
Basically not, from what I understand of sqlite. There are not any batteries included for this kind of thing beyond help from other libraries afaik.
<!-- github-comment-id:4266328031 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Hi!
Today i saw write conflict in logs. Probably we need to add locking to sqlite write thread.
Whoops, good catch! Thanks.
i believe problem may be not fixed
i received same error for image built from master @ commit
3b7e2737eeRemoteTerm for MeshCore
v3.11.3·unknown
@jkingsman sorry for tagging, cannot reopen issue
https://github.com/chrisdavis2110/remote-terminal-meshcore/commit/cde4d1744e5448baa11d0f5ee90fedf5b91c9633
i don't see there any changes to event_handlers.py or packet_processor.py, they could be missed
Ack; will take another look.
Okay I've pushed another commit that is a bit more meaningful of a change; moving all our DB traffic to a more context/locky method. TBH I'm not sure exactly what the problem here is -- of course, a DB concurrency issue, but I've had my brain and a bunch of agents scrambling over the codebase to try and repro this failure and I can't even do it in a contrived way, thus I cannot confirm my fix. Hopefully this does it; if not, I'll come back around for a more aggressive whack.
Here's an interesting possible cause for that exact error ("cannot commit transaction - SQL statements in progress"):
https://stackoverflow.com/questions/1049293/sqlite-error-cannot-commit-transaction-sql-statements-in-progress-using-java
=> it happens when a commit is executed while here are unfetched return values.
Yes, the issue is definitely around in-flight data fetching; I just wasn't able to force the codebase into a reproduceable flow [that I had any confidence in actually being the root of the problem]. The fix I pushed should hopefully be the solution with some bigger-picture transaction isolation.
Fingers crossed.
I just found it interesting that this issue is not only an issue of concurrent read access vs. write access but may also be related to unfetched return values from e.g. an INSERT statement that includes RETURNING.
But despite SQLITE3 having a bunch of locking mechanisms (like read locks that can be upgraded to write locks, see https://www.sqlite.org/lockingv3.html) - I've not yet digged into the python API to check how they leverage locking.
But maybe this will be handy - a lightweight SqliteWorker library that streamlines all DB access into a threadsafe queue with only a single dedicated worker thread doing all DB access:
https://medium.com/@roshanlamichhane/sqlite-worker-supercharge-your-sqlite-performance-in-multi-threaded-python-applications-01e2e43cc406
Yeahhhh the whole time I was troubleshooting this I kept waffling on just cutting over to a connection pooler or some other more meaningful kind of sequence control that's less miserable to operate on.
Basically not, from what I understand of sqlite. There are not any batteries included for this kind of thing beyond help from other libraries afaik.
I'm going to close this -- feel free to open a new issue if the problem recurs.