-
1. Re: Using security to end a long-running request?
starksm64 Dec 6, 2004 6:58 PM (in response to craigdberry)Sounds like a bad idea to me. How can checking a boolean flag at some key point in the workflow add significant overhead to a 3+ hour transaction? It could even be externalized to a custom interceptor with a jmx component to set/unset the abort state.
-
2. Re: Using security to end a long-running request?
craigdberry Dec 6, 2004 8:36 PM (in response to craigdberry)The problem is that you don't just poll the flag once; you have to do it over and over. To make it work in a cluster, the flag has to be implemented as a clustered singleton mbean, which means that every lookup has to go through JNDI, which has relatively high overhead.
In our app, there are no places that get executed often enough to be useful as abort check points, yet seldom enough not to bog things down if every pass through them involves a JNDI lookup and mbean flag check.
So...any thoughts on non-polling-based techniques? -
3. Re: Using security to end a long-running request?
starksm64 Dec 6, 2004 8:43 PM (in response to craigdberry)Yes, as I said a custom interceptor that has an abort state which is managed via some injection mechanism, jmx, jms, etc.
-
4. Re: Using security to end a long-running request?
craigdberry Dec 7, 2004 2:55 PM (in response to craigdberry)Ah, now I see what you're saying. Thanks.
I suppose there'd be no good way to cluster the injected abort state without doing an mbean lookup on every call rather than injecting to a static field in the interceptor from the jmx manager, though. That's dealable with, however, since in a cluster we'll presumably know what node the problem thread is running on. -
5. Re: Using security to end a long-running request?
starksm64 Dec 7, 2004 6:45 PM (in response to craigdberry)A jms topic listener that sets the abort state in the interceptor could work.