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 -~----------~----~----~----~------~----~------~--~---
