Re: [mdr-users] custom implementation recycling?

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


-- 
Hans Schippers
Research Assistant of the Research Foundation - Flanders (FWO - Vlaanderen)
http://www.win.ua.ac.be/~hschipp/
Formal Techniques in Software Engineering (FoTS)
University of Antwerp
Middelheimlaan 1
2020 Antwerpen - Belgium
Phone: +32 3 265 38 71
Fax: +32 3 265 37 77