Асинхронные события Adobe AIR SQLite не отправляются

Question

Работа над приложением, которое очень интенсивно использует локальную базу данных sqlite.Первоначально это было настроено для синхронного взаимодействия с базой данных, но при таком интенсивном использовании мы довольно часто видели «зависание» приложения на короткие периоды.

После выполнения рефакторинга асинхронного обмена мы видим другую проблему.Приложение кажется гораздо менее надежным.Работа, кажется, просто не завершена.После большой отладки и настройки проблема, похоже, заключается в том, что обработчики событий базы данных не всегда улавливаются.Я вижу это конкретно, когда начинаю транзакцию или закрываю соединение.

Вот пример:

con.addEventListener(SQLErrorEvent.ERROR, tran_ErrorHandler);

con.addEventListener(SQLEvent.BEGIN, con_beginHandler);

con.begin(SQLTransactionLockType.IMMEDIATE);

В большинстве случаев это работает просто отлично.Но время от времени con_beginHandler не срабатывает после вызова con.begin.Это позволяет нам иметь открытую транзакцию, которая никогда не будет зафиксирована и может в действительности прервать будущие запросыПри исследовании этой же проблемы с обработчиком закрытия соединения, одним из решений было просто отложить его.В этом контексте было нормально подождать даже несколько секунд.

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

Переход к чему-то подобному, кажется, делает транзакцию более надежной, однако это действительно увеличивает время, необходимое для завершения приложения.действия.Это очень тяжелое приложение, поэтому даже добавление 200 мс оказывает заметное влияние.Но что-то такое короткое, как 200 мс, похоже, не решает проблему полностью.Это должно быть 500-1000 мс или выше, чтобы я перестал видеть эту проблему.

Я написал отдельное приложение AIR, чтобы попытаться провести стресс-тестирование нашего кода и транзакций, но не могу воспроизвести этов этой среде.У меня даже есть попытка сделать что-то, что «заморозит» приложение (длинные циклы, которые выполняют некоторую математическую или другую обработку), чтобы увидеть, является ли напряжение приложения причиной их пропуска, но все кажется надежным.

I 'м в недоумении, как решить эту проблему на данный момент.Я даже попытался запустить con.begin от события привязки, просто чтобы добавить больше времени.Единственная вещь, которая, кажется, работает - это чрезмерно длинные таймеры / тайм-ауты, которые я не считаю приемлемым решением.

Кто-нибудь еще сталкивался с этим?Есть какой-то трюк для асинхронизации, который я пропускаю?

Answer 1

У меня было еще несколько идей, чтобы попробовать после освежающих выходных, ни одна из которых не удалась;Тем не менее, во время этих попыток и дополнительных расследований я наконец нашел образец для этой проблемы.Несмотря на то, что это не происходит последовательно, когда это случается, это довольно последовательно относительно того, где это происходит.Во время проблемных процессов есть 1 или 2 места, которые пытаются очистить БД после очистки данных, чтобы уменьшить размер файлов.Я думаю, что проблема здесь компактна, не была должным образом включена в асинхронный поток.Поэтому, пока мы пытаемся сузить базу данных, мы также пытаемся запустить новую транзакцию.Так что, если время от времени компакт занимает немного времени, мы можем повесить трубку.Я думаю, что предполагаемое поведение было для обработки асинхронных событий, когда транзакция, наконец, запущена, а не просто произошла вообще, но это действительно имеет некоторый смысл.