[Glass] DependentsFields and multiple gems...

[Mariano Martinez Peck]

On Thu, Feb 27, 2014 at 8:11 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> 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 <
> 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
>>
>>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140228/936ccc1a/attachment-0001.html>