Re: [mdr-users] custom implementation recycling?

Yes, it is an intended behavior - only MOFIDs are serialized in case of 
objects. Objects are serialized just once.
Martin

SainTiss wrote:

>Coming back to this once more, is this also guaranteed to work if you want keep a reference to another storable?
>
>e.g. I've got JMI objects A and B, and I'd like to have a reference to A in the custom implementation of B, but I don't want this reference to be available in the JMI interfaces.
>I guess I could use a slot/property for this, so that everything will be serialized in MDR. But then I was wondering if the referred A object wouldn't be serialized twice: once because it is in MDR, and once more because it is in B's slot. This would not be desirable I think, since B would then actually have a copy of A, instead of a reference to it.
>
>I've done a little test, and it seems that there is no copy, and the two A objects are the same, but is this indeed behaviour I can count on?
>
>Thanks,
>
>Hans
>
>On Tue, 14 Jun 2005 20:06:58 +0200
>Martin Matula <[email protected]> wrote:
>
>  
>
>>That's correct. In addition to these four slots, you can use 
>>"properties" - a key-value pairs for the same purpose as slots 
>>(getProperty(), setProperty() methods). The advantage of slots is that 
>>they are faster (to work with and to de-serialize). These are 
>>undocumented features we use in some MDR applications. The methods are 
>>defined in StorableBaseObject.
>>Martin
>>
>>SainTiss wrote:
>>
>>    
>>
>>>As far as I can see, it works up to 4... So you could say you get a fixed 
>>>number of "hidden slots" (i.e. 4), which you can use to store information you 
>>>don't want to be (trivially) accessible through the JMI interfaces...
>>>
>>>At least that's how I understand this...
>>>
>>>Kind Regards,
>>>
>>>Hans
>>>
>>>On Tuesday 14 June 2005 18:54, Steffen Zschaler wrote:
>>> 
>>>
>>>      
>>>
>>>>I've still got a question on this. I don't know much on how the slots
>>>>work, but what do I do if I have more than one attribute to store? Do I
>>>>just say getSlot2()? Where do these methods come from?
>>>>
>>>>Best regards,
>>>>
>>>>Steffen
>>>>
>>>>SainTiss wrote:
>>>>   
>>>>
>>>>        
>>>>
>>>>>Hi,
>>>>>
>>>>>Hmm, is this an "undocumented feature"? I can't seem to find any
>>>>>information on this... Is there any?
>>>>>
>>>>>Still, it seems to work, so thanks :)
>>>>>
>>>>>Also, since I read you recently became a father, congratulations :)
>>>>>
>>>>>Kind Regards,
>>>>>
>>>>>Hans
>>>>>
>>>>>On Tue, 14 Jun 2005 16:22:05 +0200
>>>>>
>>>>>Martin Matula <[email protected]> wrote:
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>SainTiss wrote:
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>Apparently, it's got more to do with garbage collection being handled
>>>>>>>differently on different systems, instead of different JDK's as I
>>>>>>>erroneously thought...
>>>>>>>
>>>>>>>Point is, I was trying to add an attribute to the custom implementation,
>>>>>>>which is not present in the MOF model... So obviously I would need the
>>>>>>>same custom implementation be associated with the same JMI object all
>>>>>>>the time, otherwise the value of my additional attribute wouldn't be
>>>>>>>preserved...
>>>>>>>
>>>>>>>Unfortunately, it seems that these custom implementation wrappers can be
>>>>>>>garbage collected when there is no reference to them or their wrapped
>>>>>>>JMI object in scope. If I keep a reference to the custom implementation
>>>>>>>wrapper, then it seems like the JMI object is assigned the same wrapper
>>>>>>>if it's fetched from MDR later on... But I'm not sure if I can count on
>>>>>>>that...
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>Yes, you can count on that. This is how it works.
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>Also, keeping references to these wrappers isn't the most pretty
>>>>>>>solution...
>>>>>>>
>>>>>>>Is there a solution/workaround here?
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>A better solution would be to use getSlotX()/setSlotX() methods in the
>>>>>>underlying storable object to store the value of the additional
>>>>>>attribute - this way you can be sure the value is persisted with the
>>>>>>values of other modeled attributes.
>>>>>>Your custom impl. code could look like this:
>>>>>>
>>>>>>public void setAttribute(String value) {
>>>>>>  _getDelegate().setSlot1(value);
>>>>>>}
>>>>>>
>>>>>>public String getAttribute() {
>>>>>>  return (String) _getDelegate().getSlot1();
>>>>>>}
>>>>>>
>>>>>>Regards,
>>>>>>Martin
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>> 
>>>
>>>      
>>>
>
>
>  
>