Home/ Questions/Q 6692581
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T05:53:02+00:00

Working on an application that has very heavy use of the local sqlite db.

  • 0

Working on an application that has very heavy use of the local sqlite db. Initially it was setup for synchronous database communication, but with such heavy usage we were seeing the application “freeze” for brief periods fairly often.

After doing a refactor to asynchronous communication we are seeing a different issue. The application seems to be far less reliable. Jobs seem to simply not complete. After much debugging and tweaking the problem seems to be the database event handles not always being caught. I’m seeing this specifically when beginning a transaction or closing the connection.

Here is an example:

con.addEventListener(SQLErrorEvent.ERROR, tran_ErrorHandler);

con.addEventListener(SQLEvent.BEGIN, con_beginHandler);

con.begin(SQLTransactionLockType.IMMEDIATE);

Most of the time this works just fine. But every now and then con_beginHandler isn’t hit after con.begin is called. This makes it so we have an open transaction that never gets committed and can really hang up future requests. When investigating this same issue with the connection close handler, one of the solutions was to simply delay it. In that context it was OK to wait even several seconds.

setTimeout(function():void{ con.begin(SQLTransactionLockType.IMMEDIATE); }, 1000);

Changing to something like this does seem to make the transaction more reliable, however, that really stretches out the time it takes for the application to complete actions. This is a very db heavy application, so even adding 200ms has a noticeable affect. But something as short as 200ms also doesn’t seem to fully solve the issue. It has to be 500-1000ms or higher in order for me to stop seeing this issue.

I’ve written a separate AIR application to try and stress test our code and the transactions, but am unable to reproduce this in that environment. I even have it try to do something that will “freeze” the application (long loops that do some math or other processing) to see if application strain is what makes them misfire, but everything seems reliable.

I’m at a loss for how to resolve this at this point. I even tried running con.begin off of a binding event, just to add more time. The only thing that seems to work is excessively long timers/timeouts, which I don’t think is an acceptable solution.

Has anybody else run into this? Is there some trick to async that I’m missing?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I had a few more ideas to try after the refreshing weekend, none of which panned out; however, during these attempts and more investigations I finally found a pattern to the issue. Even though it doesn’t happen consistently, when it does happen it is fairly consistent on where it happens. There are 1 or 2 spots during the problematic processes that try to compact the DB after doing data clearing, in order to help keep the file sizes smaller. I think the issue here is compact wasn’t worked into the async flow properly. So while we are trying to compact the db, we are also trying to start up the new transaction. So if the compact takes a bit of time every once in a while, then we get a hang up. I think the assumed behavior was for async event handling to dispatch when the transaction is finally started instead of just never happening at all, but this does make some amount of sense.

    • 0