JBossDeveloper

So what would happen in the case of async invocations? Does the whole state contained in the invocation go across the wire, the interceptors stay in memory on the client, and when get the callback (with all it’s state), then returns back to interceptors that are waiting?

"juha@jboss.org" wrote:

"Bill Burke" wrote:

I agree with Marc. 99% of use cases wil not want to chance the interceptor stack. try/catch simplifies the programming model.

Try - finally simplicity is not a point (if - else achieves the same). Variable visibility for a <u>stateful</u> interceptor however is a good point.

So we come back to the discussion of stateless vs. stateful interceptors. If state is needed, should it belong to the interceptor or to the invocation?

Should all interceptors be stateless and can be shared across POJO's (scalability). Or do we build stateful interceptors -- interceptor instance per POJO (very high number of instances even on a small interceptor stack if a lot of POJO's are instrumented).

What you're arguing for (or marc) is an interceptor instance per POJO (when stateful). However, intuition says keep everything stateless as much as possible (that is, let state live within an invocation -- like HTTP -- but the server should remain stateless).

Should there be a distinction in the interfaces between stateless and stateful interceptors (for instance, the Interceptor and SharedInterceptors that exist in the JMX base)? Do we always require a stack of interceptor instance per POJO?

"juha@jboss.org" wrote:
Thinking about it a little further, even the TX interceptor case state is only meaningful for the lifetime of that invocation. Keeping the state around in memory of the server when there is no ongoing invocation seems a little wasteful.

Consider for instance a POJO I've instrumented as transactional. This POJO gets invoked once a week. Why should I keep the state of that transactional interceptor in memory on my server for a whole week if I only need it for few milliseconds once a week. For such a case it would make sense (from resource usage point of view) to have a stateless TX interceptor and hold that state in memory for the few milliseconds it takes to invoke my POJO.

With EJB we did not have this issue as the interceptor stack was per container, not per object identity.

Stateful implementations are usually easier to implement than stateless though. However, people have managed to build easy-to-use APIs on top of stateless HTTP invocations (Servlet API) that hides the complexity from the developer so why could we not do the same? Is implementing servlet Filters difficult, do we need a different model from that?

"telrod" wrote:
So what would happen in the case of async invocations? Does the whole state contained in the invocation go across the wire, the interceptors stay in memory on the client, and when get the callback (with all itÂ’s state), then returns back to interceptors that are waiting?

Sure. Really trying to understand how the client side part of the interceptor stack will be maintained when making an async call that is waiting on a callback.

Scenario would be walk through the interceptor chain and make async call and then return back up the interceptor chain. Then server makes callback on the client. Does the callback on the client have any visibility to the original invocation's interceptor chain?

Whether an instance of the interceptor is created perVM, perClass, or perInstance. Currently you can get perVM and perClass because the framework provides a Factory plugin so you could pass in a pointer to an MBean if so desired.

So what is the semantics of Invocation.invokeNext(newInterceptors[]) in case of a shared interceptor?

invokeNext(newInterceptors[]) is a kludge I put it for remoting to work correctly.
Without it, it used the wrong stack when it got to the server pojo.

It needs to be redone properly, when we've defined how one "container" hands
an invocation to another one and restores the original state when it returns.

Regards,
Adrian