-
1. Re: Anybody feel like reconstructing?
> So I've been to the Jboss course ('... JBoss is
> simple ...')
yep that is what the course is there for.
> What should end up in the cache, and when? How does
> the cache relate to locking, and to persistence?
good question. Just did the same in Paris :) Ok so basically ending up in cache just means putting a reference with an object tree under a key. Period. that is the put. There is no notion of "state validity" or notion of locking at this point. Just a map where you can lookup and replicate in a cluster.
> After a client has obtained a reference (CMP
> scenario), every invocation is transformed into an
> invocation object, containing tx info, object type
> info, object pk info, method name, and method
> arguments.
In the case you are using DP yes. As you correctly identify this is the CMP case we teach you in the class. In the case of pure AOP 4.0 there may not be an EJB... but I digress... go on.
> When the invocation object arrives on the server it
> is routed to and MBean through a set of
> interceptors.
true, for EJB. For AOP there is a POJO no MBean.
> The security interceptor looks if there are any
> security constraints attached to the method call.
yep :) you got the class.
> The tx interceptor checks the tx requirements for the
> call: required, requires new, not supported, supports
> etc.
Stop giving all the goodies ;)
> O.k. now the actual state of the called object must
> be associated with the call.
negative.
> This is where the cache comes up. If the EJB is not
> in the cache, then the persistent manager has to
negative, negative.
> associated an instance from the pool with the data
> from the db, insert it in the cache, and return the
> the object.
were you sleeping on tuesday morning? who was your teacher? we are talking CMP2.0 meaning full control of get/set operations (we know when you need state, it is when you call get). It is also where AOP comes in full force. We instrument get/set just like we did CMP2.0. See?
>
> To construct the state using the ACID AOP, not only a
> cache instance needs to be obtained, but also the
> recorded changes need to be applied.
>
> Anybody feel like reconstructing?
ok the key is to think with CMP2.0, you correctly identified all the points in the class but then put them together and you will see that state recording is an AOP feature. Yes? see the AOP forum for early discussion with Bela and how we instrrument references to dostate change recording within transactions.
>
> Sanne
Keep your sanity you are almost there. -
2. Re: Tying cache to JMX: the options
Before I get started, here's how I want to *use* it:
org.jboss.cache.CacheImpl is a class which has public getters, setters and methods. Now my requirements:
1. I do *not* want to have to write an MBean (e.g. CacheImplMBean) for CacheImpl.
2. I do *not* want to mess with xdoclet either (to generate the CacheImplMBean)
3. I want some generic 'MBean-Adapter' which I instantiate in CacheImpl, that should take care of all MBean stuff, e.g. providing MBeanMetadata etc. This adapter probably has to use reflection, or can be an XMBean or whetever
4. [optional] Provide an XML file which helps the MBean Adapter determine which getters/setters/methods to expose, and which not.
So, in summary, I don't want to have any offline tasks (like code generation). I want all of this to be dynamically done at runtime.
Okay, see my further comments below.
> 1. Using standard MBeans with XDoclet
> 2. Using XMBeans using an xml file created by XDoclet
> 3. Using XMBeans using reflection (not yet implemented)
>
> The following is a less viable option:
>
> 4. Using dynamic MBeans
>
> Option 1. means that CacheImpl functions will have
> javadocs so that XDoclet can generate the
> CacheXMBean.
Hmm, rather not...
> Same goes for option 2: but XDoclet then generates an
> xml file for the XMBean.
Even worse.
> Option 3 can be implemented fairly easily by messing
> around with the XMBean modelmbean. The XMBean already
> contains reflection code: it is used to deploy
> standard MBeans based on reflection the ImplMBean
> interface ...
Now we're talking... Can XMBeans be used *without* XML files ?
> Question remains whether this should be considered no
> standard, geeky.
How cares ? Let's do what we think is best.
> Option 4 is less viable since the CacheImpl should
> extend a class which implements the DynamicMBean
> interface so that the reflection couldt take place.
So are you saying delegation won't work ? I mean the MBeanAdapter could use delegation (?)
> I don't know if it is possible at all, but it certainly
> sounds geeky and offstandard since the functionality
> ends up being the same as the XMBean solution.
If it is the same as XMBean, and XMBean covers what we want to do, then let's go with XMBeans...
Cheers,
Bela -
3. Re: Tying cache to JMX: the options
I think it would be useful to look at the discussions going on on the AOP forum. They are discussing ways of creating dynamic proxies for any POJO by means of the AOP framework. This would allow for crazy stuff like adding an interface (and code implementing it) to an existing class without having to restart the JVM...
So maybe this would solve our Dynamic MBean feature ? It would be really nice to be able to simply take an existing class and say "now this instance should implement the DynamicMBean interface *and* the Cache interface" by simply adding some code to it *AT RUNTIME* !
Sanne, you want to have a look into this ?
Bela -
4. Re: Tying cache to JMX: the options
> I think it would be useful to look at the discussions
> going on on the AOP forum. They are discussing ways
> of creating dynamic proxies for any POJO by means of
> the AOP framework. This would allow for crazy stuff
> like adding an interface (and code implementing it)
> to an existing class without having to restart the
> JVM...
It is trivial to add the DynamicMBean interface to an existing yes. Dynamic Proxies alone would allow us to do that if we declare a class to be of "dynamic management" class. However you still need to implement the "invoke()" call to do what you want in it.
Frankly in this particular case I think we are complicating the sauce for nothing. The simplest here is to go with a TRIVIAL StandardMBean as the cache is not going to move a lot, it's interfaces will be defined by the JCache API, so WE know what they are going to look like.
In other words bela, write the fucking interface to the cache :) and be done with it. That way you can management the cache programatically through JMX IF YOU NEED IT. I think the only trick here is to make sure that the CacheMBean thingy is smart about how to classify stuff, we have been talking about several hashmaps in there (maybe per class, per application, per logical I don't know) but stuff that will make sure the call is fast. -
5. Re: Tying cache to JMX: the options
Hi Bela,
I'm back from the course. I've read the reply of marc.
I think I'm checking out at this point. The discussion of what is most simplest is growing over my head/harder then what just works. AOP is uncharted territory at the moment, others know better.
Only one tip left: dynamic mbeans NOT using automatic config (XMBean approach) can be faster if the interface methods are called in the invoke method directly as opposed to the standard/xmbean strategy which uses reflection to call the methods. In 1.4.1 this optimization is almost trivalized though.
I'll see if I can contribute in another place.
Regards,
Sanne -
6. Re: Tying cache to JMX: the options
> I'm back from the course. I've read the reply of
> marc.
> I think I'm checking out at this point.
Marc scared you that much ? :-)
> The
> discussion of what is most simplest is growing over
> my head/harder then what just works. AOP is uncharted
> territory at the moment, others know better.
They may think they know better :-) AOP is experimental, lots of cool things to be done, but also lots of errors to be made. Time will tell.
> I'll see if I can contribute in another place.
No problem, you may want to stay tuned to this forum though...
Bela -
7. Re: Tying cache to JMX: the options
i agree with marc, this is a mute point - get it implemented.
bela, when the interface is stabilized, you can move it to be a dynamic mbean - since we do know that the speed up improvements are fairly impressive from standard to dynamic. but who cares until you have a stable interface defined?