[Glass] DependentsFields and multiple gems...

[Mariano Martinez Peck]

Hi guys,

Does anyone have an insight about this issue?

Thanks a lot in advance,


On Fri, Feb 28, 2014 at 10:41 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

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



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