Sebastián:

Podes tratar de revivir el thread:
<http://groups.google.com/group/comp.lang.smalltalk.dolphin/browse_thread/thread/eef5f8b8f5299947/44f04d0252c5142b?lnk=gst&q=WAProcessMonitor#44f04d0252c5142b>

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

Responder a