Flutter, Moor and WorkManager

[MartinHlavna]

I am developing flutter application (at the time just for Android, but with iOS support planned for later). Application operates in two ways:

• Flutter UI with most of the business logic (Foreground isolate, started with main method) (FG)
• Some automatic tasks performed on background using android WorkManager (Which uses Flutter Background Isolate) (BG)
• Both isolates are using Database

Since we need to use Database in "thread-safe" manner we are trying to use Moor database framework, with moor_ffi interface to talk to Sqlite server.

Moor claims to achieve it's "thread-safety" by spawning the third Isolate (MoorIsolate). This isolate is the only one that talks to the database. Queries executed in BG and FG are sent to this isolate using SendPort/ReceivePort, executed and returned to caller Isolate.

However all Moor example suggest spawning MoorIsolate from FG isolate. Which draws my attention to following concerns.

1. What happens to the MoorIsolate if the FG Isolate "dies"

• If user exits by pressing the back button on last screen in Navigotor?
• If APP is not visible for some time and the OS decides to free up it's memory.
• If users "force-kills" app in settings (this should ideally be only case where MoorIsolate dies)

2. In BG isolate we are using IsolateNameServer to construct MoorIsolate. Is there any way we can detect if Isolate is still running?

[simolus3]

What happens to the MoorIsolate if the FG Isolate "dies"

I don't have a lot of experience writing Flutter apps with background work. But if the process dies, the MoorIsolate goes along with it of course. If you don't have a special setup that should happen on the same scenarios where the FG Isolate stops.

Moor claims to achieve it's "thread-safety" by spawning the third Isolate

Note that the only real threading issue is that sqlite migrations can't run in a transaction. In the case that you create or upgrade the same database at roughly the same time, inconsistencies can occur. So if your WorkManager doesn't do migrations and you don't need real-time synchronization to the UI, you can safely open the database twice without spawning another isolate.

Considering battery life, you probably don't want a persistent isolate running all the time (not like Android would allow that). It looks like the workmanager package creates a new FlutterEngine for background tasks, and I'm not sure if two different FlutterEngines can communicate with each other in Dart. If it's possible to have a SendPort/ReceivePort across engines, you can also use a MoorIsolate across that (just spawn one if none is running, and stop it as soon as it's no longer used).

[MartinHlavna]

Note that the only real threading issue is that sqlite migrations can't run in a transaction. In the case that you create or upgrade the same database at roughly the same time, inconsistencies can occur. So if your WorkManager doesn't do migrations and you don't need real-time synchronization to the UI, you can safely open the database twice without spawning another isolate.

We are using sqflite in production where we are experiencing weird issue. Long story short, everything looks like it is "threading" issue where one isolate does'nt flush content to the database file or one isolate flushes over data changed in another isolate - but even trasactions are commited without errors. It just looks like that database restores sometimes to and older state.

We started migration to moor mainly because of this problem - we can bypass sqflight and even SDK thanks to amazing moor_ffi. So we are naturally afraid of any potential threading issues and want to be sure.

Should it be safe to start separate MoorIsolate in BG and FG?

Thanks.

[simolus3]

Should it be safe to start separate MoorIsolate in BG and FG?

That could be problematic with the migration issue if the BG and FG create the database at roughly the same time. Apart from that, I don't see any potential threading issues (moor_ffi ships a threadsafe sqlite on Android).

[MartinHlavna]

Thanks for reply.

Closing as it looks like it is working setup after some time