[Glass] DependentsFields and multiple gems...

[Martin McClure]

On 03/04/2014 11:44 AM, Mariano Martinez Peck wrote:
> 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
>     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 haven't looked into this in detail, but your analysis above sounds 
correct. You should be able to make a dependents dictionary persistent, 
and it will work. But you need to think about how to update the 
dependents in a pattern that will not cause transaction conflicts. Also 
think about whether the responses to the update messages will modify any 
persistent objects, and whether those modifications could cause 
transaction conflicts. I suspect that this need for careful planning is 
why we normally keep the dependents dictionary as a transient object.

Regards,

-Martin