Adobe AIR SQLite异步事件未调度

处理大量使用本地sqlite db的应用程序。最初它是为同步数据库通信而设置的，但由于使用量如此之大，我们经常看到应用程序在短时间内冻结

在对异步通信进行重构之后，我们看到了一个不同的问题。应用程序的可靠性似乎要低得多。工作似乎根本就没有完成。经过大量调试和调整后，问题似乎是数据库事件句柄并不总是被捕获。我在开始交易或关闭连接时特别注意到了这一点

以下是一个例子：

con.addEventListener(SQLErrorEvent.ERROR, tran_ErrorHandler);

con.addEventListener(SQLEvent.BEGIN, con_beginHandler);

con.begin(SQLTransactionLockType.IMMEDIATE);

大多数情况下，这一切都很好。但每次调用con.beginHandler后，con_beginHandler都不会被击中。这使得我们有一个从未提交的开放事务，并且可以真正挂起未来的请求。在使用连接关闭处理程序研究同一问题时，解决方案之一就是简单地延迟它。在这种情况下，甚至可以等待几秒钟

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

更改为类似的方式似乎确实会使事务更加可靠，但是，这确实会延长应用程序完成操作所需的时间。这是一个非常高分贝的应用程序，因此即使增加200毫秒也会产生明显的影响。但短至200毫秒的时间似乎也不能完全解决这个问题。它必须是500-1000ms或更高，以便我不再看到此问题

我已经编写了一个单独的AIR应用程序，试图对我们的代码和事务进行压力测试，但无法在该环境中重现。我甚至让它尝试做一些事情，冻结应用程序的长循环，进行一些数学或其他处理，看看应用程序紧张是否是导致它们失火的原因，但一切似乎都是可靠的

我现在不知道如何解决这个问题。我甚至试着从绑定事件开始运行con.begin，只是为了增加更多的时间。唯一有效的办法是超时时间过长，我认为这不是一个可接受的解决方案

---

还有其他人碰到过这个吗？有没有我错过的一些异步技巧？

在这个令人耳目一新的周末之后，我还有一些想法要尝试，但都没有成功；然而，在这些尝试和更多的调查中，我终于找到了问题的模式。即使它不是始终如一地发生，但当它发生时，它在发生的地方是相当一致的。在有问题的进程中，有1或2个点在执行数据清除后尝试压缩数据库，以帮助保持较小的文件大小。我认为这里的问题是compact没有正确地工作到异步流中。因此，在我们尝试压缩数据库的同时，我们也尝试启动新的事务。因此，如果紧凑型车每隔一段时间就需要一点时间，那么我们就会遇到一个问题。我认为假设的行为是在事务最终启动时分派异步事件处理，而不是根本不发生，但这确实有一定的意义