Vulcan (software)

1. Portabilidad: Vulcan fue desarrollado simultáneamente en cuatro plataformas: Microsoft Windows de 32 bits utilizando el compilador de Microsoft Visual Studio 7, Linux de 32 y 64 bits para AMD64/Opteron utilizando varias versiones de gcc, y Solaris de 64 bits utilizando el compilador Sun Forte C++.
2. Rendimiento para un único procesador: Pruebas corridas sobre Win32 demuestran mejoras en el rendimiento frente a Firebird 1.5.
3. Rendimiento sobre SMP: En una arquitectura SMP de cuatro procesadores, Vulcan registra cerca de 3,5 veces más velocidad que en un sistema de procesador simple bajo carga intensiva.
4. Compatibilidad: Los programas escritos para Firebird, funcionan sin necesidad de cambios sobre Vulcan simplemente recompilándolos.

En el proceso de alcanzar estos objetivos, Vulcan alcanzó aún más. A pesar de que Vulcan mantiene mucho del código de Firebird, ha realizado cambios radicales en su organización y arquitectura.esta es un BD multi hilo

1. Arquitectura de procesos

   Con Vulcan resurge la arquitectura original de Interbase actualizada para reflejar la tecnologías de hardware y software actuales.

2. Archivos de configuración

   Los archivos de configuración de Vulcan son compatibles con los de Firebird, pero agregan nuevas capacidades.

3. Gestores de seguridad configurables

   Diferentes organizaciones requieren diferentes niveles de autorización de usuarios. Vulcan provee una forma para resolver este requerimiento e introduce varias mejoras en la administración de la información de autenticación.

4. Validación de usuario

   Los archivos de configuración de Vulcan pueden especificar una fuente de autenticación por base de datos. También agrega sentencias SQL para crear. actualizar y eliminar usuarios.

5. Integración de SQL

   Vulcan mueve DSQL al interior del DBMS, haciéndolo más eficiente, y eliminando duplicación de metadatos.

6. Gestor de trancas

   La notificación de trancas basada en señales fue remplazada por la basada en hilos de ejecución y las dos variantes del gestor de trancas (lock manager) se recombinaron.

7. Seguimiento de llamadas

   El "dispatch module" de Vulcan (Y-valve) permite llevar un log de sesión de llamadas, sobre la base de un archivo de configuración. Las opciones son seguimiento de llamadas, resultados o sentencias SQL.

8. Cambios internos de Vulcan

   La mayoría de los cambios en Vulcan son internos. Sus efectos en el performance y confiabilidad del DBMS se notan en las aplicaciones cliente, pero sin cambiar el API ni otras interfaces de usuario.

9. Hilo "Garbage Collect"

   Firebird 1.5 utiliza un hilo de ejecución separado para realizar el "Garbage Collection", cuando es compilado como "SuperServer". Firebird 2.0 usa "Garbage Collection" cooperativa o un hilo de ejecución, según las circunstancias. Vulcan usa solamente "Garbage Collection" cooperativa.

1. Firebird: Firebird "SuperServer" maneja múltiples hilos de ejecución, pero solo se ejecuta uno a la vez, lo cual representa una arquitectura adecuada cuando se tiene un típico servidor con un único procesador. Cada solicitud opera en un hilo diferente. Un planificador interno permite a un hilo ejecutarse por un determinado período, luego lo detiene e inicia otro. Este tipo de manejo previene que una única solicitud compleja bloquee todas las demás. En Firebird, un hilo nunca puede ser detenido mientras actualiza estructuras de datos críticas.
2. Vulcan: En Vulcan. los hilos son ejecutados en forma paralela y son manejados por el planificador del sistema operativo. Este algoritmo funciona bien para en sistemas multi-procesador simétricos(SMP), pero requiere un mecanismo diferente para proteger las estructuras de datos críticas.

Algunas funcionalidades de Firebird 1.5 aún no han sido implementadas por completo en Vulcan. Estas son: las interfaces con el servidor local WNET y XNET, la sentencia SQL "Execute", y el API para servicios. Además, algunas áreas necesitan trabajo adicional: La estructura del archivo de configuración necesita algo de trabajo para asegurar compatibiladad en actualizaciones. La arquitectura remota (módulos de red remotos) y el uso de XDR reflejan tecnología de principios de los 80's y deben ser actualizados. Otras áreas ofrecen oportunidades que pueden ser explotadas con el fin de mejorar el producto, incluyendo el motor interno de SQL y el caché de sentencias compiladas. El "Getway provider" está pensado para proveer un puente entre futuras versiones de Interbase y Firebird, y aunque está demostrada su factibilidad se encuentra incompleto. Finalmente, el administrador de eventos parece haber sufrido en la migración a Vulcan.

La imagen anterior muestra la planificación para reunir las dos ramas de desarrollo, Firebird 2.0 y Vulcan, en función de generar un producto mejor que tenga las ventajas de ambos.La intención es fusionar los códigos base de estas aplicaciones con el fin de generar la versión 3.0 de Firebird. Será basada en la rama de desarrollo de Vulcan y tendrá su arquitectura modular más algunas nuevas funcionalidades, además de todas las mejoras hechas en Firebird 2.0.

• Firebird

• Vulcan Development