Spanish jRDC2: A ver si alguien puede ayudarme a "liberar" la base de datos cuando el servidor esté en "reposo"

[Gabino A. de la Gala]

Buenos días.

Estoy trabajando con una aplicación B4J haciendo de servidor con el jRDC2.

En una de las instalaciones que tengo hechas, estoy trabajando contra una base de datos firebird y de funcionamiento me está yendo perfectamente, pero me he dado cuenta de que las copias de seguridad de la base de datos no las estoy pudiendo hacer como hasta ahora, ya que parece que el jRDC2 no "libera" en ningún momento a la base de datos a no ser que detengas el servidor B4J. En cuanto lo cierras, puedes ver como el fichero físico de la base de datos en el disco duro actualiza la fecha y hora al momento actual, con o cual está claro que de alguna manera, el servidor tenía algo abierto en la BD.

He probado a "tocar" la parte del servidor y preparar un procedimiento para llamar a:

spool.close

Con esto consigo que la base de datos se libere, pero tengo el problema de que cuando hago la siguiente petición para obtener datos desde el cliente me lanza una excepción diciendo que la conexión se ha cerrado. (y eso que en el código fuente del jRDC2 me ha parecido ver que se hace una llamada spool.connect (o algo así ya que hablo de memoria) cada vez que se lanza un sql.

A ver si alguno me puede dar una pista de por donde "probar".

Un saludo.

 

[roerGarcia]

Se supone que el jRDC2 puede ser detenido desde el mismo codigo... tal vez programarlo para que vuelva a arrancar o re-arrancarlo con un batch enviado desde la aplicacion cliente.

Sub Handle(req As ServletRequest, resp As ServletResponse)
    Log("jRDC is halting... ")
    ExitApplication2(0) 'exit the application. Without this call the program will just hang.
End Sub

Habia un hilo en el foro de un "Jar Monitor", en ese se hace un shell para determinar que procesos JAVA estan corriendo (los b4js) y se puede terminar uno con otro shell. Entonces, seguramente se puede enviar otro para hacer arrancar el server jRDC2.

Saludos

 

[josejad]

Hola Gabino, ¿con qué herramienta haces el backup?
No sé si usas la oficial de firebird. Según ellos

For example, if you use Winzip to create a compressed copy of a database and you do it when users are accessing the system, the chances of a successful restore of that database are slim. You must either always use the gbak or nbackup tools which know how the database works, or, use gfix to shut the database down completely before you even attempt to backup the database file(s)

Firebird’s gbak Backup and Restore Utility

www.firebirdsql.org

 

[josejad]

Hola Gabino, no sé si algunas de estas soluciones te han ayudado, pero échale un ojo a alguna de las funciones que indica OliverA (que es un máquina con jRDC2) en este post.
En especial te podría interesar:

1) Beyond the /rdc and the /test URL's, this server also exposes /shutdown and /restart. As their names imply, /shutdown will shut down jRDC2 and exit the program. /restart will cause the jRDC2 server instance to be restarted (without restarting the complete application), which in turn allows it to reload the configuration file

También puede ser interesante este otro proyecto
No sé si con alguno de los dos podrías automatizar la parada de jRDC2 antes de tu backup

saludos,

 

[Gabino A. de la Gala]

Hola Gabino, ¿con qué herramienta haces el backup?
No sé si usas la oficial de firebird. Según ellos

Firebird’s gbak Backup and Restore Utility

www.firebirdsql.org

Hasta ahora lo tenía con un programa de copias de seguridad que copiaba todas las carpetas de la aplicación, y que antes de hacerse se aseguraba de que no hubiera nadie dentro del programa de gestión.

Ahora, al añadir el jRDC2 creo que no voy a tener más remedio que cambiar el sistema y utilizar el GBAK desde línea de comandos. (O detener el servidor b4j a una determinada ahora y volver a arrancarlo a otra, o pararlo al iniciar la copia y arrancarlo al finalizarla).

Pero bueno, me gustaba más que la base de datos estuviera cerrada cuando realmente no se está accediendo a datos para evitar posibles sustos por apagones y demás.

Muchas gracias de todas formas a todos por las ideas.

Un saludo.

 

[Gabino A. de la Gala]

Hola Gabino, no sé si algunas de estas soluciones te han ayudado, pero échale un ojo a alguna de las funciones que indica OliverA (que es un máquina con jRDC2) en este post.
En especial te podría interesar:


También puede ser interesante este otro proyecto
No sé si con alguno de los dos podrías automatizar la parada de jRDC2 antes de tu backup

saludos,

Muchas gracias por los links.
Yo ahora detengo el servidor si hay un fichero stop.txt en la carpeta del servidor. Pero hacerlo mediante llamada web también me parece interesante.
La verdad es que los dos pueden ser interesantes.
El segundo puede que compre el código para aprender cosas.

 

[OliverA]

Google Translate:
Un plan de respaldo que no requiera apagar jRDC2 podría ser algo como esto:
1) Pero el servidor jRDC2 está en modo de respaldo. En este modo, todas las solicitudes a / rdc devuelven un código de error 503
2) Utilice la URL / backup para informar a un cliente si se está realizando una copia de seguridad.

Entonces, al recibir un código de error 503, el cliente puede verificar la URL / backup para ver si se está realizando una copia de seguridad (podría ser tan simple como que el servidor devuelva "verdadero" o "falso"

3) En el modo de respaldo, jRDC2 permite finalizar las solicitudes existentes. Nota: sería necesario establecer un mecanismo para rastrear la conexión existente
4) Una vez que todos los clientes hayan terminado (o hayan agotado el tiempo de espera), deje que jRDC2 cierre el grupo y luego copie la base de datos en otra ubicación. El software de copia de seguridad puede hacer una copia de seguridad de los archivos en esta ubicación.
5) Una vez que se haya copiado la base de datos, reinicie el grupo, salga del modo de respaldo y comience a aceptar solicitudes de clientes una vez más

De esta manera, no se necesitan modificaciones en el DBRequestManager real en el lado del cliente. Habría que programar el cliente para poder detectar estas fases de respaldo. Esto se hace comprobando el código HTTP después de que una solicitud no tuvo éxito en el cliente. Si el código HTTP es 503, el cliente puede entonces
a) Informar al usuario que la conectividad de la base de datos no está disponible temporalmente
b) Verifique la URL / backup en el servidor y hágalo cada (solo por ejemplo) 100ms hasta que termine. Luego reanude cualquier actividad de la base de datos
c) Un cliente también siempre puede verificar primero la URL / backup antes de realizar una solicitud. En una red interna, esto no debería plantear problemas de tiempo.
d) Y así sucesivamente ...
==================================================================
Original:
A backup plan that would not require shutting down jRDC2 could be something like this:
1) But jRDC2 server into backup mode. In this mode, all requests to /rdc return a 503 error code
2) Use the /backup URL to let a client know if a backup is happening.

So upon receveing a 503 error code, the client could check the /backup URL to see if a backup is happening (could be as simple as the server returning "true" or "false"

3) In backup mode, jRDC2 allows existing requests to finish. Note: a mechanism for tracking existing connection would need to be established
4) Once all clients are done (or timed out), let jRDC2 close the pool and then copy the database to another location. The files in this location can then be backed up by the backup software
5) Once the database is copied, restart the pool, come out of backup mode and start accepting client requests once more

This way no modifications are needed to the actual DBRequestManager on the client side. One would have to program the client to be able to detect these backup phases. This is done by checking the HTTP code after a request was not succesful on the client. If the HTTP code is 503, the client can then
a) Inform the user that the database connectivity is temporarily unavailabe
b) Check the /backup URL on the server and do so every (just for example) 100ms until done. Then resume any database activity
c) A client could also always first check the /backup URL before doing a request. On an internal network, this should pose no time issues
d) And so on...