multithreading - ¿Existen buenas prácticas de seguridad de hilos GreenDAO?
thread-safety (2)
No tengo experiencia con greenDAO, pero la documentación está aquí: http://greendao-orm.com/documentation/queries/
Dice:
Si usa consultas en varios subprocesos, debe solicitar forCurrentThread () en la consulta para obtener una instancia de consulta para el subproceso actual. A partir de greenDAO 1.3, las instancias de objetos de Query están vinculadas a su propio hilo que crea la consulta. Esto le permite establecer parámetros de forma segura en el objeto de consulta, mientras que otros subprocesos no pueden interferir. Si otros subprocesos intentan establecer parámetros en la consulta o ejecutan la consulta vinculada a otro subproceso, se lanzará una excepción. Así, no necesitas una declaración sincronizada. De hecho, debe evitar el bloqueo, ya que esto puede ocasionar interbloqueos si las transacciones simultáneas utilizan el mismo objeto de consulta.
Para evitar esos puntos muertos potenciales por completo, greenDAO 1.3 introdujo el método forCurrentThread (). Esto devolverá una instancia de subproceso local de la consulta, que es seguro para usar en el hilo actual. Cada vez que se llama aCurrentThread (), los parámetros se establecen en los parámetros iniciales en el momento en que se construyó la consulta utilizando su generador.
Si bien en la medida en que puedo ver, la documentación no dice explícitamente nada acerca de los subprocesos múltiples que no sea esto, parece bastante claro que se maneja. Se trata de varios subprocesos que utilizan el mismo objeto de consulta, por lo que claramente varios subprocesos pueden acceder a la misma base de datos. Ciertamente, es normal que las bases de datos y DAO manejen el acceso concurrente y hay muchas técnicas probadas para trabajar con cachés en esta situación.
Tengo una oportunidad con greenDAO y hasta ahora va bastante bien. Una cosa que no parece estar cubierta por los documentos o el sitio web (o en cualquier lugar :() es cómo maneja la seguridad de los hilos.
Sé lo básico que se menciona en otra parte, como "usar una única sesión de dao" (práctica general para Android + SQLite), y entiendo bastante bien el modelo de memoria Java. Los internos de la biblioteca incluso aparecen seguros para hilos, o al menos construidos con esa intención. Pero nada de lo que he visto cubre esto:
GreenDAO almacena en caché las entidades por defecto. Esto es excelente para un programa completamente de un solo hilo: transparente y un aumento masivo del rendimiento para la mayoría de los usos. Pero si, por ejemplo, loadAll() y luego loadAll() uno de los elementos, estoy modificando el mismo objeto globalmente en mi aplicación. Si lo estoy usando en el hilo principal (por ejemplo, para mostrar) y actualizando la base de datos en un hilo en segundo plano (como es correcto y correcto), hay problemas obvios de hilos a menos que se tenga un cuidado especial.
¿GreenDAO hace algo "debajo del capó" para protegerse contra problemas comunes de subprocesos en el nivel de aplicación? Por ejemplo, modificar una entidad en caché en el subproceso de la interfaz de usuario mientras se guarda en un subproceso en segundo plano (¡es mejor que no se intercalan, especialmente cuando se modifica una lista)? ¿Existen "mejores prácticas" para protegerse contra ellos, más allá de las preocupaciones generales sobre la seguridad de los hilos (es decir, algo que greenDAO espera y funciona bien)? ¿O es que toda la memoria caché tiene fallas desde un punto de vista de seguridad de aplicaciones multiproceso?
Por defecto, GreenDAO almacena en caché y devuelve instancias de entidad en caché para mejorar el rendimiento. Para prevenir este comportamiento, necesita llamar:
daoSession.clear()
para borrar todas las instancias en caché. Alternativamente usted puede llamar:
objectDao.detachAll()
para borrar instancias en caché solo para el objeto DAO específico.
Tendrá que llamar a estos métodos cada vez que desee borrar las instancias almacenadas en caché, por lo que si desea desactivar todo el almacenamiento en caché, le recomiendo que los llame a sus métodos de acceso de sesión o DAO.