Transacciones. Duda Existencial.

[usuario1000]

Gracias a todos por vuestra paciencia.


Retomo este tema porque aún no lo tengo claro.


Supongo que vuestras aclaraciones son buenas cuando la aplicación no es DATASNAP, es decir Cliente - Servidor y todos los componentes están accesibles, pero en mi caso no están accesible.



Me surge la siguiente duda:



- El control de las transacciones las hago desde el Cliente supongo, y no desde el Servidor. Y si las tengo que hacer desde el Cliente tengo que insertar en el formulario(donde realizo una llamada a una función de alta que se ejecuta en el servidor),un componente TFDTransaction y aquí viene el problema, ¿como le digo a este componente que se conecte con el componente de "TFDConnection" que está en el "formulario ServerMethods1" del programa SERVIDOR.



Perdonad que siga insitiendo, pero hasta que no resuelva este asunto no puedo seguir programando puesto que veo un riesgo muy alto introducir datos desde distintos terminales que tocan varias tablas sin realizar transacciones para asegurar la información.


Gracias de antemano a todos.

[mamcx]

Ok. Transacciones es realmente algo simple. Es como tener certeza que el mundo no ha cambiado mientras diste unos pasos mas.

Si tienes un vble:

Código SQL [-]
a = 1
a = 2
total = 1 + a

puedes pensar que se ejecuta todo en el exacto orden que estas leyendo, y que total terminara en 3.

Pero en un ambiente paralelo o asincronico y al acceder una variable mutable accesible por MULTIPLES (posibles) PROCESOS:

Código SQL [-]
Proceso 1: a = 1
Proceso 1: a = 2
Proceso 2: a = 0 
Proceso 1: total = 1 + a

no puedes presumir que el orden de las acciones es el que estas leyendo en codigo. Porque multiples procesos pueden, en cualquier momento, "cambiar el mundo" bajo tus pies.

Asi, que mientras este solamente afectando una sola "variable"

Código SQL [-]
Proceso 1: a = 1

puedes dejarlo en manos del componente / motor.

Pero si necesitas mantener la CERTEZA que el mundo no ha cambiado, ten en cuanta que el motor NO PUEDE ASUMIR:

Código SQL [-]
12:00.1am  Proceso1: a = 1
12:00.2am  Proceso1:a = 2
12:00.3am  Proceso1total = 1 + a

porque totalente pude ser:

Código SQL [-]
12:00.1am  Proceso1: a = 1
4:00 pm  Proceso1:a = 2

asi que para indicarle que un conjunto de instrucciones REALMENTE son secuenciales, debes encapsularlas en una transaccion:

Código SQL [-]
TRASACCION 1
   12:00.1am  Proceso1: a = 1
   12:00.2am  Proceso1:a = 2

Asi, que si, es necesario usarlo incluso en SELECT, si hay UN CONJUNTO DE SELECTS que logicamente DEBEN LEER SOBRE EL MISMO CONJUNTO DE DATOS.

Si no, tendras una "lectura fantasma".


Debes leer sobre las propiedades ACID para completar tu entendimiento:

https://es.wikipedia.org/wiki/Aislamiento_(ACID)

[usuario1000]

Empezado por mamcx

Ok. Transacciones es realmente algo simple. Es como tener certeza que el mundo no ha cambiado mientras diste unos pasos mas.

Si tienes un vble:

Código SQL [-]a = 1 a = 2 total = 1 + a


puedes pensar que se ejecuta todo en el exacto orden que estas leyendo, y que total terminara en 3.

Pero en un ambiente paralelo o asincronico y al acceder una variable mutable accesible por MULTIPLES (posibles) PROCESOS:

Código SQL [-]Proceso 1: a = 1 Proceso 1: a = 2 Proceso 2: a = 0 Proceso 1: total = 1 + a


no puedes presumir que el orden de las acciones es el que estas leyendo en codigo. Porque multiples procesos pueden, en cualquier momento, "cambiar el mundo" bajo tus pies.

Asi, que mientras este solamente afectando una sola "variable"

Código SQL [-]Proceso 1: a = 1


puedes dejarlo en manos del componente / motor.

Pero si necesitas mantener la CERTEZA que el mundo no ha cambiado, ten en cuanta que el motor NO PUEDE ASUMIR:

Código SQL [-]12:00.1am Proceso1: a = 1 12:00.2am Proceso1:a = 2 12:00.3am Proceso1total = 1 + a


porque totalente pude ser:

Código SQL [-]12:00.1am Proceso1: a = 1 4:00 pm Proceso1:a = 2



asi que para indicarle que un conjunto de instrucciones REALMENTE son secuenciales, debes encapsularlas en una transaccion:

Código SQL [-]TRASACCION 1 12:00.1am Proceso1: a = 1 12:00.2am Proceso1:a = 2


Asi, que si, es necesario usarlo incluso en SELECT, si hay UN CONJUNTO DE SELECTS que logicamente DEBEN LEER SOBRE EL MISMO CONJUNTO DE DATOS.

Si no, tendras una "lectura fantasma".


Debes leer sobre las propiedades ACID para completar tu entendimiento:

https://es.wikipedia.org/wiki/Aislamiento_(ACID)

Hola Mamcx, en lineas generales sé que hacen las transacciones y te agradezco tu aclaración, pero mi problema es como conectar un componente que tengo en el Cliente con otro componente que tengo en el Servidor para poder usar el componente de Transacciones en el Cliente.


Gracias.

[usuario1000]

Al hilo de lo anterior me surge una nueva duda y es la siguiente:


- Si un usuario realiza un cambio en la base de datos y por lo que sea se ejecuta el ROLLBACK, ¿esto afectaría a otro usuario que este realizando cambios en ese mismo momento en la base de datos?. Quiero entender que son sesiones diferentes y aunque la base de datos es única para todos los usuarios, unos no interfieren con los otros, no?


Gracias a todos.

[Casimiro Noteví]

Cada uno ve "el mundo" en el momento que inició la transacción. Pero ve el mundo como estaba en ese momento confirmado. Si un usuario inicia una transacción y otro usuario inicia otra transacción, aunque el primero cancele los cambios, el segundo seguirá viendo lo que había cuando lo inició.
Resumiendo, solamente lo que se confirma (commit) es lo que ven todos.