Subprocesos - Swift SDK

Espere a que se completen las escrituras asincrónicas

El SDK proporciona un Bool para indicar si el dominio está realizando una escritura asincrónica. La variable isPerformingAsynchronousWriteOperations se convierte en true tras una llamada a una de las siguientes opciones:

• writeAsync

• beginAsyncWrite

• commitAsyncWrite

Esto se mantiene hasta que se completen todas las operaciones de escritura asíncrona programadas. Si bien esto es cierto, impide el cierre o la invalidación del dominio.

Confirmar o cancelar una escritura asíncrona

Para completar una escritura asincrónica, usted o el SDK deben llamar a:

• commitAsyncWrite

• cancelarAsyncWrite

Al usar el writeAsync método, el SDK gestiona la confirmación o cancelación de la transacción. Esto ofrece la comodidad de la escritura asíncrona sin necesidad de mantener manualmente el estado vinculado al ámbito del objeto. Sin embargo, en el writeAsync bloque, se puede llamar explícitamente commitAsyncWrite a cancelAsyncWrite o. Si se regresa sin llamar a ninguno de estos métodos,: writeAsync

• Confirma la escritura después de ejecutar las instrucciones en el bloque de escritura.

• Devuelve un error

En cualquier caso, esto completa la operación writeAsync.

Para tener más control sobre cuándo confirmar o cancelar la transacción de escritura asíncrona, use el método beginAsyncWrite. Al usar este método, debe confirmar explícitamente las transacciones. Si regresa sin confirmar una escritura asíncrona, la transacción se cancela. beginAsyncWrite devuelve un ID que puede pasar a cancelAsyncWrite.

commitAsyncWrite Confirma asincrónicamente una transacción de escritura. Este paso persiste los datos en el dominio. commitAsyncWrite puede tomar un bloque onComplete. Este bloque se ejecuta en el hilo de origen una vez que la confirmación se completa o falla con un error.

Llamar a commitAsyncWrite retorna inmediatamente. Esto permite que quien llama continúe mientras el SDK realiza la E/S en un subproceso en segundo plano. Este método devuelve un ID que se puede pasar a cancelAsyncWrite. Esto cancela la invocación pendiente del bloque de finalización. No cancela la confirmación en sí.

Puede agrupar llamadas secuenciales en commitAsyncWrite. Agrupar estas llamadas mejora el rendimiento de escritura, especialmente cuando las transacciones en lotes son pequeñas. Para permitir la agrupación de transacciones, configure el parámetro isGroupingAllowed en true.

Puedes llamar a cancelAsyncWrite en beginAsyncWrite o commitAsyncWrite. Al llamarlo en beginAsyncWrite, se cancela toda la transacción de escritura. Al llamarlo en commitAsyncWrite, solo se cancela un bloque onComplete que hayas pasado a commitAsyncWrite. No se cancela la confirmación en sí. Necesitas el ID del beginAsyncWrite o del commitAsyncWrite que quieres cancelar.

Crear una cola en serie para usar Realm en un hilo en segundo plano

Al usar Realm en un subproceso en segundo plano, cree una cola serial. Realm no admite el uso de dominios en colas concurrentes, como la cola global().

// Initialize a serial queue, and
// perform realm operations on it
let serialQueue = DispatchQueue(label: "serial-queue")
serialQueue.async {
    let realm = try! Realm(configuration: .defaultConfiguration, queue: serialQueue)
    // Do something with Realm on the non-main thread
}

Pasar instancias a través de subprocesos

Las instancias Realm de,, Results Listy las instancias administradas de Objects están confinadas al subproceso. Esto significa que solo puede usarlas en el subproceso donde las creó. Sin embargo, Realm proporciona un mecanismo llamado referencias seguras para subprocesos que permite copiar una instancia creada en un subproceso a otro.

let realm = try! Realm()
let person = Person(name: "Jane")
try! realm.write {
    realm.add(person)
}
// Create thread-safe reference to person
@ThreadSafe var personRef = person
// @ThreadSafe vars are always optional. If the referenced object is deleted,
// the @ThreadSafe var will be nullified.
print("Person's name: \(personRef?.name ?? "unknown")")
// Pass the reference to a background thread
DispatchQueue(label: "background", autoreleaseFrequency: .workItem).async {
    let realm = try! Realm()
    try! realm.write {
        // Resolve within the transaction to ensure you get the
        // latest changes from other threads. If the person
        // object was deleted, personRef will be nil.
        guard let person = personRef else {
            return // person was deleted
        }
        person.name = "Jane Doe"
    }
}

func someLongCallToGetNewName() async -> String {
    return "Janet"
}
@MainActor
func loadNameInBackground(@ThreadSafe person: Person?) async {
    let newName = await someLongCallToGetNewName()
    let realm = try! await Realm()
    try! realm.write {
        person?.name = newName
    }
}
@MainActor
func createAndUpdatePerson() async {
    let realm = try! await Realm()
    
    let person = Person(name: "Jane")
    try! realm.write {
        realm.add(person)
    }
    await loadNameInBackground(person: person)
}
await createAndUpdatePerson()

let person = Person(name: "Jane")
let realm = try! Realm()
try! realm.write {
    realm.add(person)
}
// Create thread-safe reference to person
let personRef = ThreadSafeReference(to: person)
// Pass the reference to a background thread
DispatchQueue(label: "background", autoreleaseFrequency: .workItem).async {
    let realm = try! Realm()
    try! realm.write {
        // Resolve within the transaction to ensure you get the latest changes from other threads
        guard let person = realm.resolve(personRef) else {
            return // person was deleted
        }
        person.name = "Jane Doe"
    }
}

extension Realm {
    func writeAsync<T: ThreadConfined>(_ passedObject: T, errorHandler: @escaping ((_ error: Swift.Error) -> Void) = { _ in return }, block: @escaping ((Realm, T?) -> Void)) {
        let objectReference = ThreadSafeReference(to: passedObject)
        let configuration = self.configuration
        DispatchQueue(label: "background", autoreleaseFrequency: .workItem).async {
            do {
                let realm = try Realm(configuration: configuration)
                try realm.write {
                    // Resolve within the transaction to ensure you get the latest changes from other threads
                    let object = realm.resolve(objectReference)
                    block(realm, object)
                }
            } catch {
                errorHandler(error)
            }
        }
    }
}

let realm = try! Realm()
let readEmails = realm.objects(Email.self).where {
    $0.read == true
}
realm.writeAsync(readEmails) { (realm, readEmails) in
    guard let readEmails = readEmails else {
        // Already deleted
        return
    }
    realm.delete(readEmails)
}

Utilice el mismo reino en todos los subprocesos

No es posible compartir instancias de reino entre subprocesos.

Para usar el mismo archivo de Realm en varios subprocesos, abra una instancia de Realm diferente en cada subproceso. Siempre que use la misma configuración, todas las instancias de Realm se asignarán al mismo archivo en el disco.

Reinos refrescantes

Cuando se abre un realm, este refleja la confirmación exitosa de guardar más reciente y permanece en esa versión hasta que se actualiza. Esto significa que el realm no verá los cambios que se realizaron en otro hilo hasta la siguiente actualización. Un realm en el hilo de la interfaz de usuario — o, más precisamente, en cualquier hilo del bucle de eventos — se actualiza automáticamente al inicio de ese bucle. Sin embargo, debe actualizar manualmente las instancias Realm que no se encuentran en bucles de hilo o que tienen desactivada la actualización automática.

if (![realm autorefresh]) {
    [realm refresh]
}

if (!realm.autorefresh) {
   // Manually refresh
   realm.refresh()
}

Objetos congelados

Los objetos activos y confinados en subprocesos funcionan correctamente en la mayoría de los casos. Sin embargo, algunas aplicaciones, como las basadas en arquitecturas reactivas basadas en flujos de eventos, necesitan enviar copias inmutables a varios subprocesos para su procesamiento antes de llegar al subproceso de la interfaz de usuario. Realizar una copia profunda cada vez sería costoso, y Realm no permite compartir instancias activas entre subprocesos. En este caso, se pueden congelar y descongelar objetos, colecciones y reinos.

La congelación crea una vista inmutable de un objeto, colección o reino específico. El objeto, colección o reino congelado sigue existiendo en el disco y no necesita copiarse completamente al pasarse a otros hilos. Puedes compartir libremente el objeto congelado entre hilos sin preocuparte por problemas. Al congelar un reino, sus objetos secundarios también se congelan.

Los objetos congelados no están activos y no se actualizan automáticamente. Son, en realidad, instantáneas del estado del objeto en el momento de la congelación. Al descongelar un objeto, se devuelve una versión activa del objeto congelado.

// Get an immutable copy of the realm that can be passed across threads
RLMRealm *frozenRealm = [realm freeze];
RLMResults *dogs = [Dog allObjectsInRealm:realm];
// You can freeze collections
RLMResults *frozenDogs = [dogs freeze];
// You can still read from frozen realms
RLMResults *frozenDogs2 = [Dog allObjectsInRealm:frozenRealm];
Dog *dog = [dogs firstObject];
// You can freeze objects
Dog *frozenDog = [dog freeze];
// To modify frozen objects, you can thaw them
// You can thaw collections
RLMResults *thawedDogs = [dogs thaw];
// You can thaw objects
Dog *thawedDog = [dog thaw];
// You can thaw frozen realms
RLMRealm *thawedRealm = [realm thaw];

let realm = try! Realm()
// Get an immutable copy of the realm that can be passed across threads
let frozenRealm = realm.freeze()
assert(frozenRealm.isFrozen)
let people = realm.objects(Person.self)
// You can freeze collections
let frozenPeople = people.freeze()
assert(frozenPeople.isFrozen)
// You can still read from frozen realms
let frozenPeople2 = frozenRealm.objects(Person.self)
assert(frozenPeople2.isFrozen)
let person = people.first!
assert(!person.realm!.isFrozen)
// You can freeze objects
let frozenPerson = person.freeze()
assert(frozenPerson.isFrozen)
// Frozen objects have a reference to a frozen realm
assert(frozenPerson.realm!.isFrozen)

Al trabajar con objetos congelados, cualquier intento de realizar cualquiera de las siguientes acciones genera una excepción:

• Abriendo una transacción de escritura en un reino congelado.

• Modificar un objeto congelado.

• Agregar un detector de cambios a un reino, una colección o un objeto congelado.

Puedes usar isFrozen para comprobar si el objeto está congelado. Esto siempre es seguro para subprocesos.

if ([realm isFrozen]) {
    // ...
}

if (realm.isFrozen) {
    // ...
}

Los objetos congelados siguen siendo válidos mientras el reino activo que los generó permanezca abierto. Por lo tanto, evite cerrar el reino activo hasta que todos los hilos hayan terminado con los objetos congelados. Puede cerrar un reino congelado antes de que se cierre el reino activo.

// Read from a frozen realm
let frozenPeople = frozenRealm.objects(Person.self)
// The collection that we pull from the frozen realm is also frozen
assert(frozenPeople.isFrozen)
// Get an individual person from the collection
let frozenPerson = frozenPeople.first!
// To modify the person, you must first thaw it
// You can also thaw collections and realms
let thawedPerson = frozenPerson.thaw()
// Check to make sure this person is valid. An object is
// invalidated when it is deleted from its managing realm,
// or when its managing realm has invalidate() called on it.
assert(thawedPerson?.isInvalidated == false)
// Thawing the person also thaws the frozen realm it references
assert(thawedPerson!.realm!.isFrozen == false)
// Let's make the code easier to follow by naming the thawed realm
let thawedRealm = thawedPerson!.realm!
// Now, you can modify the todo
try! thawedRealm.write {
   thawedPerson!.name = "John Michael Kane"
}

// Get a copy of frozen objects.
// Here, we're getting them from a frozen realm,
// but you might also be passing them across threads.
let frozenTimmy = frozenRealm.objects(Person.self).where {
    $0.name == "Timmy"
}.first!
let frozenLassie = frozenRealm.objects(Dog.self).where {
    $0.name == "Lassie"
}.first!
// Confirm the objects are frozen.
assert(frozenTimmy.isFrozen == true)
assert(frozenLassie.isFrozen == true)
// Thaw the frozen objects. You must thaw both the object
// you want to append and the collection you want to append it to.
let thawedTimmy = frozenTimmy.thaw()
let thawedLassie = frozenLassie.thaw()
let realm = try! Realm()
try! realm.write {
    thawedTimmy?.dogs.append(thawedLassie!)
}
XCTAssertEqual(thawedTimmy?.dogs.first?.name, "Lassie")

Comparado y contrastado con Git

Si está familiarizado con un sistema de control de versiones distribuido como Git, es posible que ya tenga una comprensión intuitiva de MVCC. Dos elementos fundamentales de Git son:

• Confirmaciones, que son escrituras atómicas.

• Ramas, que son diferentes versiones del historial de confirmaciones.

De forma similar, Realm cuenta con escrituras confirmadas atómicamente en forma de transacciones. Realm también cuenta con múltiples versiones del historial en un momento dado, como las ramas.

A diferencia de Git, que promueve activamente la distribución y la divergencia mediante bifurcaciones, un realm solo tiene una versión más reciente en un momento dado y siempre escribe en la cabecera de esa última versión. Realm no puede escribir en una versión anterior. Esto significa que sus datos convergen en una versión más reciente de la verdad.

Estructura interna

Un reino se implementa mediante una estructura de datos de árbol B+. El nodo de nivel superior representa una versión del reino; los nodos secundarios son objetos de esa versión. El reino tiene un puntero a su última versión, similar a cómo Git tiene un puntero a su confirmación HEAD.

Realm utiliza una técnica de copia en escritura para garantizar el aislamiento y la durabilidad. Al realizar cambios, Realm copia la parte relevante del árbol para su escritura. A continuación, Realm confirma los cambios en dos fases:

• Realm escribe los cambios en el disco y verifica el éxito.

• Luego, Realm establece su puntero de última versión para apuntar a la versión recién escrita.

Este proceso de confirmación en dos pasos garantiza que, incluso si la escritura falla a mitad de camino, la versión original no se corrompa, ya que los cambios se realizaron en una copia de la parte relevante del árbol. Asimismo, el puntero raíz del dominio apuntará a la versión original hasta que se garantice la validez de la nueva versión.

Ejemplo

El siguiente diagrama ilustra el proceso de confirmación:

haga clic para ampliar

1. El dominio está estructurado como un árbol. Tiene un puntero a su última versión, V1.

2. Cuando se realiza una escritura, Realm crea una nueva versión V2 basada en V1. Realm crea copias de objetos para su modificación (A ¹, C ¹), mientras que los enlaces a objetos no modificados siguen apuntando a las versiones originales (B, D).

3. Después de validar la confirmación, Realm actualiza el puntero a la nueva versión más reciente, V2. A continuación, Realm descarta los nodos antiguos que ya no están conectados al árbol.

Realm utiliza técnicas de copia cero, como el mapeo de memoria, para gestionar los datos. Al leer un valor del realm, prácticamente se ve el valor en el disco real, no una copia. Esta es la base de los objetos activos. Por eso también se puede configurar un puntero principal del realm para que apunte a la nueva versión tras validar la escritura en el disco.