Obvious problems with this approach: 1) Every invocation needs to establish an invocation context on the off chance one is needed. 2) When outside a transaction, state will be cleaned up later than what is done now (which is done in each interceptor). The reason for not doing it in an interceptor is that we want to control the order of cleanup. e.g. we don't want to release the entity lock until we have finished checking all the connections have been closed. But we don't do that until the db synchronize has been performed.
Logically, the invocation context interceptor would be better placed after the Lock/Instance/Reentrance interceptors. Especially since the instance interceptor is what gives us the object instance. But the problem with doing that is that the context on the thread local stack is cleaned up too early. Meaning transaction synchronization uses the wrong context. We cannot defer the cleanup to transaction synchronization since this invocation might not be the demarcation point of the transaction. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3861206#3861206 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3861206 ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
