Ver Mensaje Individual
  #16  
Antiguo 14-09-2016
Avatar de mamcx
mamcx mamcx is offline
Moderador
 
Registrado: sep 2004
Ubicación: Medellín - Colombia
Posts: 3.911
Reputación: 25
mamcx Tiene un aura espectacularmamcx Tiene un aura espectacularmamcx Tiene un aura espectacular
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?
__________________
El malabarista.
Responder Con Cita