ConcurrencyThrottleInterceptor - are requests queued?

[jimmyjones]

Hi all,

I am looking at using ConcurrencyThrottleInterceptor to limit concurrent requests to a part of my application where there is contention on the database.

ConcurrencyThrottleSupport doesn't seem to have a Queue for the waiting threads instead it uses Object.wait() to block threads. The problem with this approach is that:

"If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation."

So I could have an unlucky thread that is never chosen to be awakened while some other lucky threads jump the queue.

am I right in thinking that this behaviour is possible? And if so - should I worry about it?

Thanks for reading!!!

[Alarmnummer]

Hi all,

I am looking at using ConcurrencyThrottleInterceptor to limit concurrent requests to a part of my application where there is contention on the database.

There is another way to limit concurrency to the database: limit the number of connections in the connection pool.

Is there a reason not to use this approach? (it could be).

ConcurrencyThrottleSupport doesn't seem to have a Queue for the waiting threads instead it uses Object.wait() to block threads. The problem with this approach is that:

"If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation."

So I could have an unlucky thread that is never chosen to be awakened while some other lucky threads jump the queue.

am I right in thinking that this behaviour is possible?

Yes.

With Java 5 you can set the fairness property of a ReentrantLock (and his condition(s)) and this makes it possible that threads will get a turn in a certain order. With the intrinsic lock and waitset this is not possible.

And if so - should I worry about it?

A lot of concurrency control is done using the intrinsic lock and waitset and I have not heard starvation problems. So I guess that the operating system/VM makes sure that eventually some thread is called and no threads starve.

Thanks for reading!!!

You are welcome.