[Glass] DependentsFields and multiple gems...

[Dale Henrichs]

Mariano,

Yes the change:/update: "signalling" is not shared across multiple gems, so
a different scheme needs to be used ....

Some sort of persistent state change is the best cross gem notification
strategy.

Take a look at SessionMethodTransactionBoundaryPolicy>>transactionBoundary:
for an example where I compare a persistent counter with a valued that was
cached in session state and clear the ClassOrganizer cache if the counter
was incremented by another session ... as I write this I'm not sure whether
this is the best approach for your particular situation.

I assume that a local notification can be used to update some persistent
state that is persistent when the transaction is completed and then the
other gems will see that persistent state and "do the right thing"
presumably ...

I guess the missing piece for you was to actually persist the end result of
your #update:....

Dale


On Thu, Feb 27, 2014 at 2:26 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

> Hi guys,
>
> After 2 hours of debugging...I found the Seaside app I am developing is
> using the notification strategy of #changed:  , #update:
>  , DependentsFields etc...yes...don't ask why ;) I don't know why but
> somewhere inside a seaside callback I have this kind of communication.
>
> I had a very strange problem. This callback was working perfectly in
> Pharo. Was working correctly in GemStone with a single Swazzo adaptor. I
> was working correctly even using WAGemStoneRunSeasideGems with a single
> Swazzo. However....I discovered that when using multiple FastCGI adaptors
> (gems) it failed. So ... basically, if I only start one FastCGI and I
> define 1 upstream in the webserver, no problem it works. However....if more
> then 1 upsteam is alive...it doesn't work.
>
> I *think *it could be related to the DependentsFields class var and the
> lack of synchronization of it. Besides trying to use another notification
> scheme....does this sound like the problem? should I do something with the
> class var? (same as GLASS do for seaside class vars)
>
> Any help is appreciated.
>
> Best,
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140227/5ed03791/attachment.html>