[Glass] DependentsFields and multiple gems...

On Thu, Feb 27, 2014 at 8:11 PM, Dale Henrichs <[hidden email]> wrote:

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.

Hi Dale,

I am trying to understand a bit more about this issue. If I understand correct the problem is because I am using multiple gems AND the dependents stuff is not being persisted right? What I mean is....imagine for a second that Object would have class var DependentsFields. That class var should be persistent so I should NOT have problem. Am I correct?  The problem arises because the implementation of #myDependents: in GemStone is like this:

myDependents: aCollectionOrNil

"Private. Set (or remove) the receiver's dependents list."

| d |

d := SessionTemps current 

at: #'Monticello-Dependents' 

ifAbsent: [

SessionTemps current 

at: #'Monticello-Dependents'

put: Dictionary new ].

aCollectionOrNil

ifNil: [ d removeKey: self ifAbsent: []]

ifNotNil: [d at: self put: aCollectionOrNil ].

Besides the strange thing that it is being stored in a Monticello dictionary, the problem is that it is stored in a SessionTemps...which as far as I understand is local to the gem/session.

I wonder if a slight modification to this that persists the dict could work. I have only 2 or 3 classes with this. So I CAN implement #myDependents: in them and do what I want. 

 

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

And if I directly persist the dependents dict, wouldn't I be achieving that?

 

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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--
Mariano
http://marianopeck.wordpress.com