[jboss-dev] Changing meta data runtime
Jason T. Greene
jason.greene at redhat.com
Thu Sep 17 16:52:00 EDT 2009
Adrian Brock wrote:
> No. This has nothing to do with annotations, it might be
> in Carlo's use case, but that is only because he uses an
> annotation for his specific piece of metadata.
Right, I was speaking to the ejb use-case which using annotation names
as the index to general administration configuration.
> It's about how to change metadata at runtime without redeploying.
> Of course if the metadata is a deployment time only config then a
> redeploy is required.
> Requiring the profile service to understand "pushing to the interceptor"
> is not going to work, while putting it in one standard place (the mdr)
> doesn't become an n^2 problem, i.e. the profile service having to
> understand the internals of each subsystem that wants to
> be able to do runtime changes to metadata.
I should have been clearer, I didn't mean we should change the profile
service at all for this. I mean that the EJB3 code (if it wants to
support this) should provide a managed object that is published via the
profile service (setSecurityDomain property).
> But since nothing is really designed to use the MDR in this way, its not
> really an issue.
> This feature was one of Bill's and Scott's ideas, e.g. being able to
> have a default tx timeout at cluster, system, deployment, bean,
> method level, but it was never really followed through.
> (I know there were earlier threads elsewhere in the forums or
> the dev-list - just from Scott's first comment :-)
> I don't know whether Scott (or Bill) still think this is a useful idea,
> since the profile service currently uses "ManagedOperations" to
> do things like changing cache sizes, etc. at runtime.
Well, I think the unified domain model stuff we are moving to somewhat
conflicts with this notion. However, it could
> P.S. I don't see why the EJB3 layer should be involved in MDR caching.
> The MDR already has a variant that does caching and understands
> how to invalidate a piece of metadata in that cache when somebody
> modifies it at an abitrary level.
> It's not enabled by default because (at least currently)
> most metadata is only read once at deployment
> time making the caching part redundant and
> therefore extra needless work (not to mention a waste of memory).
Right that's really the issue with caching at the MDR level, it's at too
low of a level to determine if something should be cached. There really
is no reason for EJB3 to continually reread the same values, but
according to Carlo that's a side-effect of the current EJB3 design (and
it's interaction with AOP), so it was easier to front the mdr for just
the ejb related calls with a basic cache. Hopefully this work around can
be eliminated in 6.
Jason T. Greene
JBoss, a division of Red Hat
More information about the jboss-development