Advice service to be 'active'

[Alarmnummer]

Is there support/plans for advising (with AOP) a service with an executer that executes the call, so you get more control. An implementation of an Executor is the ThreadPoolExecutor (part of the new concurrency library in jdk5.0)

I sometimes have the need to do more than just make a service active (maybe his own thread) or synchronized (no own thread.. only one thread active in the service). I want to control the number of threads that are calling the service. I want to control what to do if the maximum number of threads are active (maybe a timeout.. or just wait). Maybe even control if a call has expired.

Mostly I use a ThreadPoolExecutor (jdk5.0 has good support) in a wrapper around the service, so the new service interface is the same as the original version. Calls where the caller depens on the result of the callee could be implemented by a Future, but mostly it are 'asynchronous' service interfaces (post and forget).

But this is a lot of (boring) work and I think AOP could be a better solution. A new class could be generated, based on the orginal, with the concurrency control structures in it. And even metadata could be used to add the needed information in a declarative manner.

interface FooService{
    @Active(number=2)
    void doSomething();
}

Something like this for example. Only 2 threads can be active..

So.. are there any plans to implement this? Are there problems I have overlooked? Is something like this already implemented?

[Rod Johnson]

Have you looked at ConcurrencyThrottleInterceptor? Controlling the number of threads in an instance definitely makes sense. It's often what people want to achieve with SLSB pooling (if they need it at all): controlling load rather than protecting state.

[Alarmnummer]

Have you looked at ConcurrencyThrottleInterceptor? Controlling the number of threads in an instance definitely makes sense. It's often what people want to achieve with SLSB pooling (if they need it at all): controlling load rather than protecting state.

I think this class does what I want.

But you don`t have much control:
-You can`t change the executor that executes the method call. With the executor you have control on the number of threads, the priority, the names of threadpool/threads. You even could share the same threadpool with different services.
-You can`t inject a policy how to deal with calls that exceed the limits. Maybe you want to do a endless wait... or a wait with timeout (I can imagine in a single application you want both options... I do at least)

[Rod Johnson]

True, it seems you want something more elaborate. ConcurrencyThrottleInterceptor would be a good starting point: please feed back your experience with these kind of features, in case it's something we should consider adding to Spring or Spring Modules.

[Alarmnummer]

True, it seems you want something more elaborate. ConcurrencyThrottleInterceptor would be a good starting point: please feed back your experience with these kind of features, in case it's something we should consider adding to Spring or Spring Modules.

I see 2 problems at the moment:

1) the interface of the service doesn`t have the difference between a blocking call without a timeout and with a timeout. You only can advice a method to be one of them... but you can`t use the same method in 2 different ways... (blocking.. or blocking with timeout). Solution: create 2 service interfaces.. one blocking.. one blocking with timeout. But I`m not that happy with this solution.. (and the caller doesn`t have control how long the timeout is going to be)

2) recursive calls. But this problems also was tackled by the transaction advisor.. so I`ll have to look how it was solved there.