We have millions of users, and we’ve been storing the realm db instead an app group container. Realm locks a file, the app is suspended, and the watchdog terminates the app.
This only seems to happen if the db is stored in the app group container; we no longer have need for the db to be in a container, so we want to migrate the location to the app itself.
What do I need to know in order to do this without data loss or breaking anything?
That’s an interesting bug. In reading the response from Realm, it states
On iOS (and watchOS) we do not hold a file lock the entire time the Realm file is open. We acquire one when opening the file, but release it before the initializer returns. Write transactions also hold a lock for the duration of the write, but release it once the write is complete.
which would indicate they do not have a file lock after write. We have not experienced that either.
Is it possible there’s something else in the app that’s doing a perpetual write, or potentially moving a function to say, a background thread, causing a persistent lock?
This has been a known problem as least as far back as 2017 - if you search the GitHub issues for Realm-swift for ‘deadlock’ you’ll see it’s never really been addressed.
I do not believe the file locked but rather, writes are not properly managed from the Realm SDK so that they can potentially be locking the file during a suspension that happens while a write operation is occurring.
Of course, this should be managed from within Realm and not an implementation detail for consumers to manage (although if there were documentation from Realm on specifically how to do so safely, that would be a great compromise).
Now there are some workarounds and fixes mentioned on GitHub, but our team is planning to move the realm DB from app group container to app container.
I am simply looking for guidance on how to do so without impacting users or losing data. Are there any FAQs, or discussions related to doing this?
An issue like this would have far reaching affects and needs to be addressed. I am just searching for an actual bug here - one that can be duplicated so I know what not to do in our own code.
Once that’s established, actually answering the question would be possible.
So I read through all of those “deadlock” links. The issue is that “deadlock” describes different things to different people, so many of the bug reports were not on topic… for this topic.
What I am seeing over and over is this:
@tkafka we do release the file lock on the Realm file. You need to make sure the Realm is not in use otherwise you app will continue to hold the lock. If you want to release the file lock after a write consider the following approach:
autoreleasepool {
let realm = try! Realm(...)
try! realm.write {
...
}
}
// realm will be released along with file lock after this block
and
Hi @alexeichhorn,
That’s expected. You should not run blocking code in .initial and that’s exactly what write does.
You may asynchronously dispatch calls for updateDog/updateNames .
and
Thread 2 (a background thread) is holding the write lock and attempting to synchronously dispatch work to the main thread, but the main thread is already waiting for the write lock and so things deadlock.
and then other threads that have ‘deadlock’’ issues caused by infinite loops or setting up objects that perform recursive initialization.
We’ve tried multiple gyrations to duplicate the issue and even with a massive file 2Gb worth of data, we simply can’t make it happen so I don’t know what the answer would be. We’ve never lost any data with Realm, regardless of the file structure or location. Is this maybe something related to the OS?
Do you have a minimal, reproducible example of how to make this bug appear?