Manejo de transacciones B.D. en WebService

[andres_04_08]

Hola Jhonny.

¿Será que pueden compartir algún ejemplo de código? con las respuesta del Post 7 y 8 no lo pude resolver y no lo entiendo.
Las preguntas del Post 11 quedaron sin respuesta, tal vez aclarando esas dudas puedo terminar de entender sus anteriores publicaciones.

Muchas gracias!

[mamcx]

Lo que te estan diciendo los post es que debes tener claro como es que funciona DataSnap para asi saber que es lo que debes o no alterar.

Un servidor tipo web debe operar como una cadena Solicitud -> Respuesta, idealmente, sin que los afecten el que hayan otras llamadas concurrentes. Comúnmente la BD se convierte el repositorio del estado cambiante de la aplicación.

Ahora, hace rato que no toco Delphi y menos DataSnap, asi es la razon que no te he dado nada mas concreto. Pero si tienes claro el concepto, veras que se traslada a cualquier lenguaje de programacion.

Lo que pasa ademas es que es raro que tengas ese problema a menos que haya una alteracion en como esta configurado el proyecto (porque dudo que DataSnap no provea unos defaults sanos).

Que tal si creas un proyecto en blanco con un ejemplo minimo de lo que quieres y revisas en que se diferencia del que tienes?

----

Aun mas concretamente: Todo el setup de objetos/llamadas deberias poder ponerlo en una LINEA CONTINUA, sin que haya probabilidades de que exista una vble/objeto/archivo no transaccional que pueda tocarse desde otra linea de ejecución paralela. Dentro del código servidor no debe haber creado ni compartido nada (incluso la vble threadvar!) porque entonces tendrás potencial contención entre las ejecuciones y posibilidades a varios tipos de errores (como dead-locks) y ademas, el desempeño sera pobre.

Asi que a partir de la clase que "arranca" todo, de ESTA debe armar la linea ENTRADA -> CREA OBJETO -> CREA OBJETO .... y todo debe referenciar hacia atras (ya sea como propiedad o solo vero en términos historicos).


Es claro?

[[AgustinOrtu]]

Es que el desarrollo multitier es distinto al desarrollo cliente-servidor que fomento toda la vida Delphi. Eso de poner componentes de acceso a datos en un DataModule y dejarlos alli vivitos y coleando no sirven en un ambiente web en donde no hay estado, stateless como puntualizo mamcx

Lo correcto para acceder a la base de datos es:

Llega peticion -> Peticion debe acceder a BD -> Crear conexion a la BD -> Crear Query -> Ejecutar Query -> Devolver resultado -> liberar recursos usados

En el modelo cliente servidor clasico, creas una sola conexion a la bd cuanto mucho, y luego los query/command depende de como lo hagas (no estas obligado aunque siempre lo mas sano es devolver un objeto nuevo)

[andres_04_08]

Buen día!, muchas gracias por sus respuestas.

Entendia que lo correcto para acceder a la base de datos es:

Llega peticion -> Peticion debe acceder a BD -> Crear conexion a la BD -> Crear Query -> Ejecutar Query -> Devolver resultado -> liberar recursos usados

Es por eso que BeforeDispatch instancio mi dataModule (TwsDataModule) para que se creen las conexiones y luego lo libero en el evento AfterDispatch .

Mi duda es si estaba bien crear una conexión por cada petición y en que evento se debería hacer, o si existía alguna forma de que las conexiones se creen y administren solas.