【问题标题】:optimistic locking failure iOS swift乐观锁定失败iOS swift
【发布时间】:2017-03-22 11:07:19
【问题描述】:

是的,我当然在整个互联网上进行了搜索。 但无法摆脱这个问题。

我有两个实体命名: 邮政和大众邮政。 (几乎一模一样)

当我获取帖子并更新它的属性时,比如 numberoflikes、numberofcmets 这很好。

但是当我获取 PopularPost 并尝试更新它的属性时,它会说 “乐观锁定失败”

获取、更新和保存实体的我的代码:“PopularPosts”。

let postpopFetch = NSFetchRequest<NSFetchRequestResult>(entityName: "PopularPosts")
        postpopFetch.predicate = NSPredicate(format: "id = %@", postId)
        let resultp = try? CoreDataManager.sharedInstance.managedObjectContext.fetch(postpopFetch)
        let resultDatap = resultp as! [PopularPosts]

        for object in resultDatap {

            print(object.numberOfHearts)

            if like {
                object.numberOfHearts = object.numberOfHearts + 1
                object.isLiked = true
            }else{
                (object.numberOfHearts > 0) ? (object.numberOfHearts = object.numberOfHearts - 1) : (object.numberOfHearts = 0)
                object.isLiked = false
            }
        }

        do {
            try CoreDataManager.sharedInstance.managedObjectContext.save()
            print("saved!")
        } catch let error as NSError  {
            print("Could not save \(error), \(error.userInfo)")
        }

【问题讨论】:

  • 您的核心数据堆栈是什么样的?你有多少上下文?你有亲子关系吗?你使用 NSPersistent​Container 吗?
  • 我在单例类中只维护了一个上下文。没有亲子关系。仅简单的 2 个实体。
  • 你总是在主线程上读写吗?
  • @JonRose:有时会涉及后台线程

标签: ios core-data


【解决方案1】:

通常乐观锁定失败是由两个不同的托管对象上下文试图更改相同的数据引起的。如果您同时从不同的线程不恰当地访问它,我认为即使在一个上下文中也可能会遇到这个问题。 ManagedObjectContexts 不是 阅读和写作都不是线程安全的。

我见过这样的情况,即从错误的线程访问 managedObjectContext 并且很久以后在一行没有做错的代码上发生崩溃。我建议仔细搜索您的代码,以查找对不在主线程上的核心数据的任何访问。您使用[NSThread isMainThread] 来检查您是否不在主线程上进行调试。

【讨论】:

  • 我只有一个托管对象上下文,我确实检查过以确保从主线程访问核心数据。但我仍然遇到同样的问题。光学锁定失败。怎么来的??
【解决方案2】:

在我的情况下,这是由使用 newBackgroundContext() 引起的。

我有一个可能长时间运行的任务,该任务在应用程序进入后台时开始。

即使在再次使用该应用程序之前完成,我发现后台任务后进行的所有保存都会失败。

我通过将viewContext 用于长时间运行的任务解决了这个问题。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2015-11-17
    • 1970-01-01
    • 2015-03-25
    • 2011-05-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-09-12
    相关资源
    最近更新 更多