I'm not the original author, but storing things directly in the invocation is more lightweight, you are storing in a map and don't have to store things in a threadlocal (which underlies the ThreadMetaData). The original intent for the metadata is to be "short-lived", i.e. the span of the invocations.. If you want "long-lived" metadata then you need to set it the other way, and the invocation will check whether it exists. invocation.getMetaData() checks all available scopes, but at setting time you explicitly add it -directly to the invocation -to the ThreadMetaData -to the instance advisor I guess a flag could be added to setMetaData() to specify the scope, but I think it is fine as it is? BTW on your server side you probably want to do something like | try{ | ThreadMetaData.instance().addMetaData(...); | ... | } | finally{ | ThreadMetaData.instance().clear() | } | to avoid polluting subsequent threads with non-relevant metadata View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4074502#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...