Top

Aventuras y desventuras con COM+

Aventuras y desventuras con COM+

Hoy me he estado peleando todo el día con las transacciones en COM+. Después de haber pensado el diseño de la aplicación, me he dispuesto a hacer una pequeña prueba de la arquitectura que tenía pensada y sobre todo quería comprobar que la capa de acceso a datos funcionaba como era de esperar para empezar a programar los DAOs.


 


Después de haber escrito el código, me pongo a hacer unas pruebas y me encuentro con la desagradable sorpresa de que cuando se produce una excepción, esta se lanza hacia arriba pero en ningún momento COM+ la detecta y lanza un RollBack. Primer palo. Intento comprobar que es lo que pasa y resulta que aunque en una de mis clases específico TransactionOption.Required, el código no se ejecuta nunca en el contexto de una transacción. Segundo palo.


 


Reviso, vuelvo a compilar, vuelvo a desplegar… nada… esto no tira…


 


Después de pasarme todo el día peleando, os comento la conclusión a la que he llegado:


Resulta que yo tengo una clase que es una fachada (marcada como TransactionOption.Supported) que tiene un método para cada caso de uso dentro de la fachada. Para no hacer que la clase de la fachada sea enorme, y poder marcar que casos de uso son trasaccionales y cuales no, cada método de la fachada delega en un clase Action que implementa un caso de uso concreto y que para ello se puede apoyar en otras Actions. Las Actions están unas marcadas como TransactionOption.Required o TransactionOption.Supported, según sea necesario. Todas estas clases están dentro del mismo ensamblado.


El caso es que una vez desplegado esto en COM+, parece que ocurre lo siguiente; si la fachada está marcada como TransactionOption.Supported no hay ninguna transacción aunque la acción esté marcada como TransactionOption.Required. Si la fachada está marcada como TransactionOption.Required, si hay transacciones y la cosa funciona correctamente. O sea, que parece que dentro de un mismo ensamblado, uno no puede cambiar el valor de TransactionOption, si no que siempre se mantiene el del código más exterior, el primero invocada, en este caso el de la fachada.


 


El caso es que si esto es cierto, no he visto que esté documentado en ninguna parte… snifff….

Iván González Vilaboa
1 Comment
  • anonymous

    Lo que puede estar pasando es que al momento de generar una instancia esta no es unica sino que crea una copia de la original y en ella guarda el valor por o que cuando asignar otro valor a otra ya es una nueva instancia y trae el valor predeterminado

    prueba no generar instancias sino que solo uses la de la fachada

    2 octubre, 2007 at 5:54 pm Responder

Post a Comment