Hola,
Primero de todo hemos de entender lo que se entiende por concurrencia, o lo que entiendo yo ! Yo separaría conceptos en este hilo y la problemática aquí descrita.
1.- Yo entiendo que una concurrencia es cuando muchas peticiones sobre una base de datos se realizan al mismo tiempo, pero quizas en este hilo focalizaria esta petición sobre una misma tabla/registro en el mismo momento.
2.- Hemos de entender y/o diferenciar como trabaja un BBDD como por ejemplo MySql y nuestras Dbfs.
3.- Si nos centramos ahora en nuestras Dbf's, la "concurrencia" en un registro se manejan con los propios comandos que ofrece Harbour para el bloqueo de registros, como p.e. Rlock() Unlock(),...
4.- Cuando diseñas la aplicación quizás nunca ocurra la actualización de un mismo registro por 2 o mas peticiones al mismo tiempo, pero hemos de tener en cuenta evidentemente este caso, esto es sagrado con nuestras dbfs.
5.- Vamos ahora a focalizar sobre mod_harbour. Si ejecutamos varias peticiones sobre el mod, se crean varios procesos en apache y puede ejecutar estos procesos al mismo tiempo, e intentará de actualizar una misma tabla/registro. Si tenemos bien codificado el proceso, no ha de pasar nada. Si tu tienes un registro bloqueado y viene en el mismo momento otra petición tienes solo 2 opciones: O se espera, o se va (que tiene prisa
)
6.- El problema que veo yo aquí es un tema de uso de ADS en local, y seguramente hay o tiene algún mecanismo para que actúe de una manera sencilla y monopuesto digamos. Ricardo comenta que en la versión server va todo perfecto, pues yo creo que allí esta la diferencia
7.- A nivel harbour puro y duro me he creado un pequeño test q inserto un registro en una tablita y bloqueo el primer registro para actualizarlo. Al pasar un test de apache p.e. de
100 peticiones y 10 concurrencias, el sistema funciona perfectamente, y no encontramos ninguna petición que haya fallado.
Código: Seleccionar todo
Concurrency Level: 5
Time taken for tests: 28.165 seconds
Complete requests: 100
Failed requests: 0
Total transferred: 17500 bytes
HTML transferred: 0 bytes
Como podeis observar "
Failed requests: 0"
Una vez verificada la tabla, todo es correcto: se crean 100 registros y el primero siempre se actualiza con la última petición procesada
Si me da tiempo, pondré el test en NetIO para hacer el mismo test, pero ha de funcionar de la misma manera…
8.- Es por eso, que hemos de analizar bien cada situación, entorno, arquitectura,… para poder valorar correctamente. Yo hace 15 años que no toco ADS, pero puedo pensar que los programadores de ADS no son tontos y quizás la versión local tiene algún tipo de limitación, como por ejemplo usar este tipo de concurrencias, sino quizás todo el mundo usaría este sistema y no compraría licencias, pero tampoco lo se de modo cierto, simplemente me lo imagino.
Pienso que la solución de Ricardo, que básicamente es un semáforo, es una ingeniosa solución que le permite de momento solventar este problema en modo local. Desgraciadamente un ejemplo autocontenido con las dll de ads, etc... es tiempo que necesitas para prepararlo y analizarlo. Pero en resumen, yo me quedo con esta visión, a no ser que venga otro y pueda aportar mas luz al tema.
Para acabar solo os puedo decir que durante los 5 años que trabaje con ADS (hace 15) era de lejos, el mejor sistema para trabajar con dbfs en modo cliente/servidor.
