Crash: Database inaccessible after period of time. #7164
Comments
|
Hi @ragu-pth , |
|
@pavel-ship-it Thank you for your reply. The function |
|
@ragu-pth as you are calling |
|
@leemaguire The creation and retrieval of the configuration objects is thread-safe, as both creation and retrieval are blocked by an access semaphore, as seen at the top of the file submitted in the #7088 ticket. Realm itself is billed as thread-safe, and we've never run into such issues since using this type of logic since Realm 5.x. Did something change in Realm 10.x? This issue is also happening in these cases on first launch, on the very first thread call, so it also isn't an issue due to being accessed from multiple threads. All the errors I've submitted are it being called within the single, same thread. The dispatch queues are abstracting away from threads, and run more risk as they can open Realms across an unknown number of threads in the pool. We've had issues with that in the past (Realm 4.x+), which moved us to having Realm on a dedicated background thread and main thread, so it's only used on a handful of threads for the lifetime of the app. As an aside, are there any paid Technical Support packages Realm provides and that you can point me to to escalate this issue? While an exceedingly rare problem, data integrity is paramount in our application and so I'd like to get to the root cause of this. |
|
'The dispatch queues are abstracting away from threads, and run more risk as they can open Realms across an unknown number of threads in the pool.' - This isn't true a Realm is bound to one concurrency context. @ragu-pth Realm Cocoa is built with Dispatch Queues in mind, and serial queues for that matter. So I would recommend utilising GCD. Looking back at your semaphore in #7088 I'm not sure that it properly achieves the locking mechanism you are after. Especially if you are doing things with threads a semaphore won't always guarantee mutual exclusion. |
Why wouldn't this be the case, especially if it is a semaphore of 1 and essentially operating like a lock? We've never had an issue with this in the past, whereas the GCD has let to multiple issues Example & Example #2. These issues almost destroyed that product in the past as several customers were experiencing the issue with no real traceability, and necessitated a complete rewrite where we used a single thread to manage access to the database. What can you tell me about the fixes that have been implemented since then to ensure that using GCD won't cause those same issues today? Also, where can I find information on other service level packages you offer besides the community issue submission? We are utilizing this in a healthtech company and want to get an appropriate level of support for the industry. |
|
hey @ragu-pth - Product for Realm here. If you'd like to drop me an email at [email protected] - I'd love to hear about your use case and we can discuss how we can better support you |
sync-by-unito
bot
changed the title
sync-by-unito
bot
added
the
More-information-needed
|
This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further. |
!!! MANDATORY TO FILL OUT !!!
Goals
Writing data to iOS Realm database in a stable manner over time and not have underlying database file corruption
Expected Results
No Crash
Actual Results
Crash Entitled:
please_report_this_issue_in_github_realm_realm_coreSteps for others to Reproduce
Is not reliably reproduced - Related to this ticket
Code Sample
Code snippets in 7088
Version of Realm and Tooling
Realm framework version: Latest
Realm Object Server version: N/A
Xcode version: 12.4
iOS/OSX version: iOS 14.4
Dependency manager + version: Cocoapods latest
The text was updated successfully, but these errors were encountered: