10 Replies Latest reply: Sep 9, 2002 12:27 PM by Matt Munz RSS

XMBean Persistence

Matt Munz Newbie

Paul, Juha, David, Sacha, and others,

I have been following your threads (mail and forum), and have come to the conclusion that I am one step behind on this issue.

I need to get minimal XMBean Persistence working ASAP and am happy to write the code to do so. Based on your comments, I think at least one of you may have already done this.

Would it be possible for me to see the code?

If not, any pointers on getting started with implementing this?

- Matt

  • 1. Re: XMBean Persistence
    Juha Lindfors Master

    Go ahead, there's no one working on it right now AFAIK.

    -- Juha

  • 2. Re: XMBean Persistence
    Matt Munz Newbie

    Hi all,

    Is XMBean persistence supposed to persist the metadata, data (model object state), or both?

    I've been able to get this working to a point, based on the suggestions made by David. I now have a service whose Persistence Manager class is instantiated when the model MBean is created and is invoked according to the persistence policy.

    Now it's time to fully implement the persistence manager class. It seems that, to do what I want it to do, the PersistenceManager interface should be modified. Since this is the first major diversion I'm making from the existing architecture, I thought I'd ask all of you to verify that I am on the right track.

    What is the Persistence Manager supposed to do, exactly? It occurs to me that what I want it to do is to persist the state of the object that is being managed by the MBean. For example, say I have an XMBean that has a User object as its model. If I use the JMX Agent to change the Name attribute of the User object to "Fred", then the persistence manager is called, and I would expect the persistence manager to store the string "Fred" in the persistence store.

    When I look at the persistence code on p. 222 of "JMX: Managing J2EE...", however, I see that only the metadata is persisted/loaded. The fact that the Name attribute is read/write, for example, is stored, but the actual content ("Fred") is not, as far as I can tell.

    What should I be persisting here -- data, metadata, or both?

    Thanks again for all the help so far.

    - Matt

  • 3. Re: XMBean Persistence
    Juha Lindfors Master

    only the data

    although many default impls. just serialize the whole metadat a structure but thats a bad idea

    the mbeans definition (metadata) should be separated from its state

    -- Juha

  • 4. Re: XMBean Persistence
    Matt Munz Newbie

    Juha & group,

    Could you take a look at my design questions below?

    > although many default impls. just serialize the whole
    > metadat a structure but thats a bad idea

    I assume that you are referring to default implementations in other JMX servers. I agree that the persistence mechanism should be as lean as possible, and the separation of data and metadata is important.

    Right now, I just want to get the *easiest* solution finished. Especially since I am new to this code, I'm trying to make minimal modifications at this point. As such, I am serializing/deserializing the entire metadata/data combo at this point (via the ModelMBeanInfo object).

    I have a few questions about the existing design.

    1) the ModelMBeanInfo for the ModelMBeanInvoker object is stored in an instance variable (info). This variable is passed to the invocation stack at preRegister(). ModelMBeanInvoker has a "set" accessor for this variable. There is the possibility of a disconnect here, as any calls to this set accessor after preRegister() will result in a discontinuity -- namely that the invocation stack will now have a reference to a "stale" ModelMBeanInfo object. It seems to me that the MBeanInfo instance variable (info) should be encapsulated in the ModelMBeanInvoker class, and that the invocation stack should have a reference to that class only. The stack could retrieve the info object as needed from a public ("get") accessor on the invoker object. Any objections to this?

    2) The invocation stack currently is Persistence > MBeanAttribute > Object Reference. This means that the bean is persisted *before* it is modified. So, for example, assuming persistence OnUpdate, if you try to change an attribute with value "A" to value "B", the persistence manager will store "A", then the mbean info and model object will be updated. Then, if you change "B" to "C", the persistence manager will store
    "B". As you can see, the persistence manager is always one step behind. A solution to this would be to change the invocation stack to be MBeanAttribute > Object Reference > Persistence. Again, does this make sense? Any objections?


  • 5. Re: XMBean Persistence
    Juha Lindfors Master

    > point. As such, I am serializing/deserializing the entire metadata/data combo at this point (via the
    > ModelMBeanInfo object).

    that works too, its about two lines of code

    > 1) the ModelMBeanInfo for the ModelMBeanInvoker object is stored in an instance variable (info).
    > This variable is passed to the invocation stack at preRegister(). ModelMBeanInvoker has a "set"
    > accessor for this variable. There is the possibility of a disconnect here, as any calls to
    > this set accessor after preRegister() will result in a discontinuity -- namely that the invocation stack
    > will now have a reference to a "stale" ModelMBeanInfo object. It seems to me that the
    > MBeanInfo instance variable (info) should be encapsulated in the ModelMBeanInvoker class, and
    > that the invocation stack should have a reference to that class only. The stack could retrieve the info
    > object as needed from a public ("get") accessor on the invoker object. Any objections to this?

    No objections. If I remember correctly this is how it's done in the rewrite of the invocation chain as well.


    > 2) The invocation stack currently is Persistence > MBeanAttribute > Object Reference. This means
    > that the bean is persisted *before* it is modified. So, for example, assuming persistence OnUpdate, if
    > you try to change an attribute with value "A" to value "B", the persistence manager will store "A",
    > then the mbean info and model object will be updated. Then, if you change "B" to "C", the
    > persistence manager will store "B". As you can see, the persistence manager is
    > always one step behind. A solution to this would be to change the invocation stack to be MBeanAttribute
    > > Object Reference > Persistence. Again, does this make sense? Any objections?

    As far as I remember OR interceptor fields the call and returns, so it needs to be the last one in the chain. MBeanAttribute does all the modifications to the metadata, if you persist by serializing the metadata then add the interceptor after that one.

    -- Juha

  • 6. Re: XMBean Persistence
    Trevor Squires Novice

    (xposted email too)

    Unless the ObjectReferenceInterceptor has been changed I'd have to say it won't work -- this interceptor is pretty much the last thing before the mbean instance itself.

    Rather than mess with the order of interceptors, have you considered having your interceptor persist *after* you pass the call to the next interceptor in the chain?

    Trevor

  • 7. Re: XMBean Persistence
    Juha Lindfors Master

    actually you should store on the way out, not when you're going in

  • 8. Re: XMBean Persistence
    Trevor Squires Novice

    Matt,

    this got me back out of bed again... something's not right.

    I know I said to try MBeanAttribute->Persistence->ObjRef which is what I think Juha sugessted. However, now this doesn't seem right.

    You say:

    > 2) The invocation stack currently is Persistence >
    > MBeanAttribute > Object Reference. This means
    > that the bean is persisted *before* it is modified.

    But we've both looked at the code and concluded that the PersistenceInterceptor is doing it's thing after the call to the other interceptors.

    I'm pretty sure that PersistenceInterceptor *has* to come before MBeanAttribute because a MBeanAttribute never actually passes the attribute calls to the next interceptor -- it resubmits them to the invoker as operations on the setter/getter methods (and Persistence passes operations through).

    So the behaviour you quote about the persistence manager being one step behind doesn't make much sense -- the call to PersistentMBean.store() ought to be the last thing done because it's the last thing done on the way out.

    Have you changed PersistenceInterceptor from what's in CVS?

    Trev

  • 9. Re: XMBean Persistence
    Matt Munz Newbie

    Trevor,

    > Have you changed PersistenceInterceptor from what's
    > in CVS?

    No, I haven't. You could easily check this behavior by inserting some debug statements into NullPersistence.store() and then doing some set operations on a Model MBean.

    I am willing to believe that the current order of interceptors is correct.

    At this point, I have persistence working in a minimal fashion, with the lag I mentioned previously. I'm going to be on vacation through labor day, so I probably won't be looking at this issue much until then ;)

    When I get back to work, I'll investigate this further. At that point, I'll do all the i-dotting and t-crossing necessary to start using XMBean persistence regularly.

    Thanks again for all of the support, from everyone.

  • 10. Re: XMBean Persistence
    Matt Munz Newbie

    Hi all,

    For those interested, I have been unable to reproduce the error about the lag in persistence, so it probably didn't exist ;) Sorry about the false alarm.

    - Matt