Hi, On Wed, 2010-08-18 at 19:46 -0500, Carsten Neumann wrote: > Hello Gerrit, > > On 18.08.2010 19:07, Gerrit Voß wrote: > > On Wed, 2010-08-18 at 16:07 -0500, Carsten Neumann wrote: > > short question, so I have the full picture, what was the reason behind > > r2472 because that one changed what was recorded and what was not ? > > on the cave side in our app attachments were dying when > RemoteAspect::receiveSync() cleared the newContainers vector at the end.
ok, what kind of attachments were these ? All or only a variant (MTLocal, Global) ? > The change in r2472 helped for that case and seemed to simply correct a > mixup (it does not seem to make sense to use recorded ref count changes > on the attachments if the AttachmentContainer itself is MTLocal). hmm, MTLocal does not mean ClusterLocal but I guess in most cases we actually use the combination. I'll try to track down why I changed this, my current guess would be named local containers, because it looks like it was for containers which themselves have multiple aspects but the carrying one does not. > Having thought a bit more about this now I believe > AttachmentContainer::_sfAttachments should behave like any other field, > i.e. only make unrecorded changes - if that is not the correct behavior > all other containers would have the same issue. Not unlikely but sfAttachments is the field where local and non local combinations will be most likely mixed, so finding problems there is far more likely. It is also something most other containers just derive, independent of their own global/local nature so I expect special cases in there. I'm not sure if pushing them up to every single pointer field is necessary so I'm not so worried about having special cases in there for the time being. My current plan would be to rebuild you aspect setup, somewhere in the changed/transmit pipleline something seems to get lost. Short question, is the server side one of the standard servers or a modified version ? kind regards gerrit ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
