El problea más grave es que acciones ejecutan más veces que lo que deberían. Si bien el uso de la odb reveló el problema, este comportamiento puede traer problemas impredecibles para aplicaciones Seaside.
Aún en la versión 2.8a1 eam 529 e se pueden ver cosas como esta: (extraido de un logueo al transcript) Free clients: 4 Get odb client: 52791 from process HTTPConnection>>interact Return odb client: 52791 from process HTTPConnection>>interact Return odb client: 52791 from process Copy of 349:Copy of 340:HTTPConnection>>interact Redundant return! (mutex violation?) el numero de client es el hash de la odb en el pool. El pool como decia antes esta protegido por un semaforo for mutual exclusion y el get y el return se ejecutan dentro de un critical para que justamente este garantizado que dos procesos no puedan tomar un mismo cliente. Nota: el "Get odb..." se imprime despues que terminó el critical. El proceso que es copia del 349 y que viene de la EscapeContinuation no deberia haber tomado la odb. Es plausible que no la haya tomado y la conozca porque "behind the scenes" la continuation se la copió (cosa que no se como confirmar). Si este fuera el caso entonces estaría más claro como funciona el bug de ejecutar cosas dos veces. Para un escenario como este hago la siguiente pregunta: será que las continuations de Squeak hacen algo para compensar esa doble ejecución? (quizá en la forma de copiar el proceso?) idem VW? (ya lo estoy probando a ver que tal) será que el cógo original de #critical:ifError:, que evalúa el bloque en un fork y espera el resultado, no hace eso justamente como parte de la compensación? Voy a estar haciendo algo de codigo para poner esto en evidencia y ver si hace lo mismo VW saludos, Sebastian On Aug 21, 4:06 pm, Sebastian <[EMAIL PROTECTED]> wrote: > Ah bueno! eso explica un montón de cosas. Incluída la copia del > semaforo en un estado anterior y que permite ejecutar la accion > protegida cuando deberia frenarse. No es loco porque justamente > continuations es ir para atras y para adelante en el tiempo. Esto se > esta pareciendo peligrosamente a los expedientes X de la computacion. > Concretamente eso explica el doble returnClient: y doble commit: a la > transacción. > Voy a digerir un poco todo esto > > gracias totales por la referencia Esteban > > Sebastian > > On Aug 21, 3:28 pm, "Esteban A. Maringolo" <[EMAIL PROTECTED]> > wrote: > > > Sebastián: > > > Podes tratar de revivir el thread: > > <http://groups.google.com/group/comp.lang.smalltalk.dolphin/browse_thr...> > > > Suerte :-| > > > Esteban A. Maringolo > > > 2008/8/21 Sebastian <[EMAIL PROTECTED]>: > > > > Hola gente, > > > > estoy atras de un problema un tanto inusual por decir algo. > > > Mi objetivo es usar Seaside en dolphin workers y que la sesión wrapee > > > con una transacción la respuesta del request (los porqués de esto son > > > un poquillo off-topic pero el que quiera ver una referencia puede ver > > > OmniSupport en squeaksource.com). Quedaría (simplificando el exception > > > handling) algo así: > > > > BlahSession>>withEscapeContinuation: aBlock > > > | response | > > > > ^ self database commit: > > > [response := super withEscapeContinuation: aBlock. > > > response ifNil: [ODBCannotLockObject signal: 'Re-signalled > > > from > > > ODBSession']. > > > response status = '500' ifTrue: [ODBSInternalError signal]. > > > response] > > > > Entonces todo lo que la app seaside requiere para resolver ese request > > > se hace dentro de esa transacción (sacada de un pool para aumentar > > > availability). > > > > El problema todavía no lo conozco bien pero detallo lo que vi: > > > se ve de dos formas, 1 a veces se retornan conexiones al pool que ya > > > habían sido retornadas (notar que el getClient y el returnClient: del > > > pool están protegidos con un mutex) y 2 a veces se hace un commit a > > > una transacción que ya le hicieron commit. > > > > Lo que parece estar pasando es que alguien no respeta un #critical: > > > cosa que sería totalmente chiflada a menos que continuations > > > estuvieran en el medio (son lo más loco que vi en ST hasta hoy). > > > > Destaco que Esteban para portar el Seaside a Dolphin tuvo que cambiar > > > WAProcessMonitor>>critical:ifError: > > > > | value | > > > #eamChanged. > > > mutex critical: > > > [process := Processor activeProcess. > > > [value := aBlock on: Error do: anErrorBlock] ensure: > > > [process := > > > nil] > > > ]. > > > ^ value > > > > en lugar del original de squeak que, como referencia, es: > > > > | value | > > > mutex critical: [ > > > semaphore := SeasidePlatformSupport semaphoreClass new. > > > process := [ > > > [ value := aBlock on: Error do: anErrorBlock ] > > > ensure: [ semaphore signal ] ] fork. > > > semaphore wait ]. > > > process := nil. > > > ^ value > > > > Si bien la versión Esteban anda, no termino de convencerme que estén > > > haciendo lo mismo con los procesos. Todavía no veo como pero ni pude > > > probarlo pero parecería posible que este habiendo algo que confunde > > > incluso al critical. > > > > Si alguien tiene una idea de como probar en el workspace que dos > > > procesos provenientes de continuations respetan normalmente el > > > critical me sería de gran ayuda. Hace dos días que empecé a > > > incursionar en las profundidades de las Continuations y todavía no > > > termino entenderlas. > > > > Algun paper que ayude para recomendar? > > > > gracias, > > > > Sebastian --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
