sqlite transición de las transacciones a los puntos de guardado

Question

Mi aplicación basada en SQLite actualmente utiliza transacciones, tanto para poder retrotraer como para mejorar el rendimiento. Estoy considerando reemplazar todas las transacciones con puntos de rescate. La razón es que la aplicación tiene varios subprocesos (sí, sqlite está configurado para ser seguro para subprocesos) y, en algunos casos, una transacción puede iniciarse con dos subprocesos al mismo tiempo (en el mismo db).

1. ¿Hay alguna razón para hacerlo?
2. ¿Hay algún error que deba tener en cuenta?
3. No acabo de reemplazar BEGIN, COMMIT, ROLLBACK con SAVEPOINT xyz, RELEASE SAVEPOINT xyz, ROLLBACK TO SAVEPOINT xyz?

Answer 1

It there a reason NOT to do it? 

Sí. No resolverá ninguno de los problemas que describió. Los puntos guardados se usan principalmente para poder hacer retrocesos parciales de datos. La transacción externa o punto de rescate es lo que realmente está comprometido. Nada se guarda completamente hasta que se libera el punto de salvación más externo, actualizando así la base de datos. Ya vuelves al mismo problema que tienes con las transacciones estándar.

Are there any pitfalls I need to be aware of? 

Sí. Las transacciones o puntos de rescate en una aplicación multiproceso pueden bloquear con bastante facilidad si actualiza los mismos datos en dos subprocesos diferentes, lo que supongo que es el meollo del asunto. No hay diferencia entre los dos a este respecto. Debe tener en cuenta lo que está actualizando en cada hilo y sincronizar en consecuencia.

En resumen, a menos que tenga la necesidad de hacer rollback de transacciones parcial, puntos de retorno de verdad suele dar mucho (aparte del hecho de que se nombran.)

No hay bala de plata aquí. Parece que necesita hacer un análisis serio de su aplicación y los datos que pueden actualizarse en varios subprocesos y agregar alguna sincronización en su aplicación si es necesario.