Re: [mdr-users] custom implementation recycling?

These problems arise because java.lang.Object cannot be serialized in 
MDR. The error handling is weak here, since these features are not 
documented.
Martin

SainTiss wrote:

>Good to know, thanks...
>
>Just when I was trying this out, however, I think I may have stumbled upon a bug:
>
>I noticed that, when I use a call like
>_getDelegate().setSlot1("test");
>everything is fine... However, when I do
>_getDelegate().setSlot1(new Object());
>
>it seems like transactions don't work anymore... I've got one big transaction, which I start at the beginning of my program, and stop at the end (endTrans(false) => no rollback). However, when I have a setSlot call like the second one above, the transaction is not stored (i.e. there's only one extent, MOF). If I replace the call with the first one above, it does work...
>No errors in the log file though...
>
>Or is this something which is normal somehow?
>
>Thanks,
>
>Hans
>
>On Thu, 16 Jun 2005 12:07:41 +0200
>Martin Matula <[email protected]> wrote:
>
>  
>
>>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
>>>>>>>>      
>>>>>>>>
>>>>>>>>           
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>> 
>>>
>>>      
>>>
>
>
>  
>