BD SQLite protegida por Usuario y Contraseña

[ElMug]

Empezado por roman

Aquí quería yo llegar

Mi punto es: si no implementas algún tipo de control, por muy multigeneracional que sea, el último en guardar los cambios va a machacar los cambios de los demás. La aplicación puede optar por un bloqueo optimista y, por lo menos, avisar al último usuario que alguien ya hizo cambios.

En estos términos, estamos igual que con motores no concurrentes: hay que tener un control sobre qué hacer cuando hay accesos simultáneos a la misma información.

// Saludos

Bueno, lo multigeneracional es precisamente para eso, para NO bloquear los escritos con read-locks (candados puestos al leer). Y el "aviso" es que si los que estan leyendo tratan de escribir, entonces se les rechaza su transaccion, porque el motor sabe que la version en que quieren basar su grabacion es vieja. Al menos eso es lo que hace Postgres.

[Casimiro Noteví]

Empezado por ElMug

Acceso multiconcurrente es que mas de un usuario pueda grabar en una base de datos, sin importar los mecanismos usados, y esto lo hace SQLite3 usando su Modulo Pager.
SQLite3 tambien usa dos copias de las transacciones y las usa para el roll-back y para controlar el uso simultaneo de escritos a una misma tabla.

Hablamos de editar un mismo registro, no de insertar nuevos, ahí no hay problema.

Empezado por roman

Je, je. Estás escurriendo el bulto o yéndote por la tangente. El texto que citas no resuelve el problema que menciono. Cada usuario podrá tener una vista muy coherente de los datos, pero eso no quita que uno machaca los datos del otro.

Evidentemente, si yo guardo algo y tú guardas después, ¿qué hacer?, pues mantener el último, eso es lo lógico, ¿no?.
Otra cosa distinta es que si yo abro para editar, y me voy rápido al baño. Tú mientras tanto llegas y modificas el mismo registro que yo he dejado editando. ¿Qué hacer?, ¿avisarte de que lo está editando otro usuario y no dejarte hacer nada?, ¿dejarte editarlo?, creo que lo correcto es lo último.
Luego vuelvo yo y le digo "guardar", ¿debería dejarme?, ¿debería decirme que otro usuario ya ha modificado mi registro?.

Cada una de esas preguntas admite varias posibilidades, y para ello se puede configurar a gusto del consumidor: read_commited, nowait, snapshot, etc. son parámetros para que firebird "responda" de una manera u otra, dependiendo de lo que queramos.
Habitualmente, siempre, he preferido que se guarde lo que haga el último que guarda. ¿Para qué bloquear?, además de que en la vida real no suele haber problema por eso, realmente nunca he tenido un problema por eso, pongamos un ejemplo simple:
Tenemos un cliente: codigo: 1000, nombre: empresapaco, DescuentoHabitual: 10 %
El cliente es muy bueno y el jefe dice: "al cliente empresapaco le subimos el descuento habitual al 12%"
Si nuestra empresa es un caos de organización, tenemos a todos los trabajadores de la oficina abriendo la ficha del cliente y modificando su descuento habitual. Todos sobreescriben los datos de los demás, ningún problema.
Pero si hay uno un poco sordo y entendió 14 en lugar de 12, y es el último en grabar... se quedará el 14%
¿Es un fallo de firebird, postgresql, mysql, etc.?, evidentemente, no.

En la vida real creo que es difícil encontrarse problemas con una base de datos por cosas de ese tipo, incluido sqlite

[ElMug]

Empezado por Casimiro Notevi

Hablamos de editar un mismo registro, no de insertar nuevos, ahí no hay problema.

Pues eso lo hace SQLite3 con muchisima mas facilidad:

Usuario-1 hace un cambiecillo a tira-a y Usuario-2 hace otro un cambio a tira-1 se hacen los DOS cambios, uno tras otro. Mientras la data sea valida, ambos cambios se aplican. Si la data de uno de los dos usuarios no califica, la transaccion se rechaza.

Por ejemplo, si no se permiten duplicados de registro, y el usuario-2 quiere duplicar, pues se le rechaza.

Ninguna base de datos puede cambiar un registro exactamente al mismo tiempo.

Yo creo que mal-entiendes algo, Casimiro.

Cual es el problema?

[Casimiro Noteví]

Empezado por ElMug

Por ejemplo, si no se permiten duplicados de registro, y el usuario-2 quiere duplicar, pues se le rechaza.

¿Duplicados de registro?, ¿a qué te refieres con eso?

Empezado por ElMug

Ninguna base de datos puede cambiar un registro exactamente al mismo tiempo.

Sí, con el sistema multigeneracional de firebird, van creándose "versiones" del mismo registro, al mismo tiempo.
Aunque si te refieres "exactamente al mismo tiempo".... hombre, eso es prácticamente 'casi' imposible, si varía unas millonesímas de segundos, ya no es "exactamente al mismo tiempo"

[ElMug]

Empezado por Casimiro Notevi

¿Duplicados de registro?, ¿a qué te refieres con eso?


Sí, con el sistema multigeneracional de firebird, van creándose "versiones" del mismo registro, al mismo tiempo.
Aunque si te refieres "exactamente al mismo tiempo".... hombre, eso es prácticamente 'casi' imposible, si varía unas millonesímas de segundos, ya no es "exactamente al mismo tiempo"

Duplicado de registros es que te rechazen la bd data repetida o rechazo de campos de valor exclusivo (unico).

Las versiones no se graban al mismo tiempo como dices, sino que "version" es una copia de una transaccion (basicamente) con un numero de serie o mecanismo similar. Eso es viejo y precede a la tecnica multigeneracion: Se graba la transaccion y se hace una copia de respaldo para roll back. Eso tambien lo hace SQLite3.

Los sistemas de tipo servidor que llaman multigeneracionales se apoyan en el mismo principio de la copia para rollback y esas copias no constituyen de ninguna manera el que "varios usuarios escriban en la misma tabla al mismo tiempo", cada grabacion de cada usuario graba la transaccion y la copia, uno por uno, a su vez.

De hecho, el sistema multigeneracion limita aun mas los escritos finales a las tablas, pues segun el caso, se pueden considerar grabaciones temporales, y separadas de la verdadera tabla.

SQLite hace algo similar, pero a nivel limitado, aun en su manera de-fault de controlar los locks, usando archivos temporales en memoria o en disco, con su Pager Module.

Y de hecho, permite aumentar ese control si se desea, pues tiene un modo (que no es default y se configura) que aun no se ha discutido aqui, que se llama "shared cache" y "shadow-paging".

Aqui les pongo enlace a la documentacion oficial del asunto:
SQLite Shared-Cache Mode:
http://www.sqlite.org/sharedcache.html


Y este otro link (tambien documentacion oficial de SQLite3) titulado File Locking and Concurrency Control (Control de Concurrencia):
http://www.sqlite.org/lockingv3.html

[ElMug]

Empezado por Casimiro Notevi

Aunque si te refieres "exactamente al mismo tiempo".... hombre, eso es prácticamente 'casi' imposible, si varía unas millonesímas de segundos, ya no es "exactamente al mismo tiempo"

Igual pasa con SQlite3, dos usuarios pueden grabar a la misma tabla con diferencia de tiempo de milisegundos.

Los limitaciones de SQlite3 para uso multisuario no han sido nunca en ese sentido.

[roman]

Empezado por Casimiro Notevi

Otra cosa distinta es que si yo abro para editar, y me voy rápido al baño. Tú mientras tanto llegas y modificas el mismo registro que yo he dejado editando. ¿Qué hacer?, ¿avisarte de que lo está editando otro usuario y no dejarte hacer nada?, ¿dejarte editarlo?, creo que lo correcto es lo último.
Luego vuelvo yo y le digo "guardar", ¿debería dejarme?, ¿debería decirme que otro usuario ya ha modificado mi registro?.

Claro, este es el problema. El punto es que tienes que seguir una estrategia que no pasa por simplemente guardar lo que hizo el último, sobre todo si ese último no necesariamente es el primero en abrir el registro. Y, aunque el cliente configure a su gusto, como dices, tu software tiene que saber qué hacer con la respuesta.

Bueno, en un sistema de bloqueos resulta lo mismo. El software tiene que decidir qué hacer si quiere abrir un registro bloqueado. Aunque las opciones son menos.

Ahora bien, si esto sucede muy pocas veces en la vida real, con mayor razón bastaría usar bloqueos. Incluso podríamos usar bases del tipo NoSQL que ni transacciones tienen pero que son muy cómodas de usar.

Creo que por el contrario, esto sucede con mucha frecuencia, aunque no el caso que describes y por ello la preocupación de que el gestor sea ACID. No se trata, como el ejemplo que pones, de una mala organización de l compañía en la que dos empleados editan los mismos datos. Si tienes que manejar un stock, necesariamente va a haber varios puestos accediendo a las existencias del mismo producto.

// Saludos

[Casimiro Noteví]

Ya, el ejemplo que he puesto es bastante tonto.