DCOM / MIDAS / ADO PROBLEM
Cerecred S.A.
Hardware: un servidor de base de datos Unix SCO v 5 con un motor Informix
Dynamic Server 7.3.
un servidor de aplicaciones NT 4.0 (con service pack 5).
50 clientes Win95/Win98 y WorkStation.
Modelo: RemoteDataModule con Multi Hilo, conectándose a Unix - Informix via
ADO -> OLEDB for ODBC -> ODBC -> Informix Client
tengo varios problemas para desarrollar:
- En un prinicipio, el sistema de aplicación estaba configurado como está
descripto anteriormente, pero usaba conexiones BDE -> Informix Client. En
este esquema teníamos el problema que en un momento determinado, los RDM se
"colgaban" ya que el BDE (único para todos los RDM) también se "colgaba". La
deducción que hicimos, es que ante reiteradas llamadas al BDE (modelo
multithread), en algún momento, 2 o más llamadas coincidían en tiempo y
provocaba un loop infinito. (¿ BDE es multithread ? ¿ Hay solución para
dicho problema ?
- Posteriormente, decidimos migrar a tecnología ADO (aparentemente era más
estable, y al estar implementado como liberías dinámicas, cada RDM tiene un
"motor ADO independiente". Sin embargo, solucionamos un problema pero
introdujimos otros, a saber:
- En un momento determinado, 1 o más RDM comienzan a usar más ciclos de
CPU que los que requiere. El porcentaje de uso empieza a subir en forma
abrupta hasta el 100 %, dejando el equipo, servidor y aplicación
inutilizables. (Tenemos que dar de baja el/los RDM en cuestión.
- De la misma forma, el otro problema es que en otra circunstancias,
comienzan a utilizar espacio en disco (memoria virtual) en forma creciente y
arbitraría, con lo cual, si bien el % de CPU es más o menos normal, el uso
desemedido de Disco, ocasiona un problema similar al anterior (por ejemplo,
un RDM que únicamente tiene Stores Procedures que realizan consultas de
pocas filas, terminan usando 100 de CPU y/o 250 Mb de memoria virtual).
- Algunas consideraciones a saber sobre los casos anteriormente planteados:
1.- A medida que los clientes se van conectando, se incrementa la
memoria utilizada y cuando se desconenctan no se libera toda la memoria.
2 - A veces, un proceso en el cliente se cuelga, y esto produce que se
cuelgue la aplicacion servidora y por ende todas las aplicaciones clientes
conectadas se mueren.
3 - Cuando paso mal un parametro desde un cliente esto produce que el
tiempo de cpu salte al 100%. y la aplicacion quede dando vueltas, y debo
matarla.
4 - Hicimos algunos intentos para solucionar parcialmente dichos
problemas, como por ejemplo implementar un submódulo monitor en el form que
crea las diferentes instancias de un mismo RDM, llevando una lista de
conexiones, tiempo de ejecución de cada comando, etc de forma de "matar"
algún cliente que haya ejecutado una consulta que por error devuelve
demasiados datos o que insume demasiado tiempo de CPU. De más está decir que
dichos intentos han sido en vano.
* Mi esquema de trabajo es el siguiente:
Todos las consultas acceden atravez de procedimentos almacenados. En la
aplicaion cliente utilizo DCOM y DataSetProviders. En la aplicacion cliente
utilizo AdoStoredProc y AdoDataSets , sin programacion extra en el server.
**** El Delphi Enterprise que usamos, lo tenemos con los "parches"
correspondientes
AGRADECERIA ME CONTESTEN SI POSEEN INFORMACION ACERCA DE DICHOS PROBLEMAS,
O SI CONOCEN ALGUIEN QUE TENGA UN PROBLEMA SIMILAR DE FORMA QUE ME PUEDA
AYUDAR Y/O INTERCAMBIA INFORMACIÓN.
DESDE YA MUCHAS GRACIAS
ANDRES BIMA
SUPERVISOR AREA PRODUCCION
CERECRED S.A.
German Andrade
Estimado Andres:
Tengo la impresión que los componentes de ADOExpress que vienen con Delphi 5 Enterprise no trabajan muy bien en un ambiente
'multithread' como el que describes. Hemos obtenido resultados similares trabajando con MTSDatamodules-ADOQuery-ODBCDatasource-Interbase
¿ Que versión de ADO usas ? Hemos obtenido algunos resultados positivos con ADO 2.1, pero las versiones 2.5 y 2.6 causan problemas (parece que Microsoft camina hacia atrás en esto...)
Por otro lado, los componentes de ADOExpress son muy lentos ( casi el doble del tiempo que BDE ) y tienen problemas cuando se les proporciona un estatuo SQL erróneo ( se cuelgan en lugar de reportar el error ).
Creo que se puede cambiar ADOExpress por ODBCExpress (http://www.odbcexpress.com) y obtener los mismos beneficios (conectividad, 'multithreading', 'connection pooling', etc.)
¡ Suerte !