[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ee4j-community] Tomitribe commitment to EE4J
|
Thanks for the insight David. Just to clarify my proposal on @MaxConcurrency: m
y idea is basically what pooling does, but without reusing objects.
So if you use it on a singleton bean you'll get one instance with controlled concurrency.
But if you use it on a request scoped bean, no new beans will be instantitated nor calls to methods will be accepted once the concurrency limit is met. I think this is called bulkheads?
The idea is basically the same but without forcing a pool and usable on any scope.
Your story of the map is different though and would definitely require a pool. But again since we are talking about resources, how about putting it on JCA?
Regards,
Guillermo González de Agüero
> On Oct 14, 2017, at 12:31 PM, Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
>
> Do instance pools still provide a real performance gain? I know Adam Bien did an informal test on Payara and the results where positive for EJBs, but I don't think the results are too reliable.
>
> WildFly disabled pools by default for some time ane the EJB spec doesn't even mandate a pool to exist. I doubt it's a really useful feature. An @MaxConcurrency would be more useful IMO that the pool itself (so different scopes can be used) while serving a similar purpose. And that again falls on the Concurrency Utilities side.
It's definitely an interesting subject. There's really three things to be said about it, IMO.
@Stateless usage. Most people are unaware that these beans are pooled and have essentially a concurrent limit. They often hurt themselves as a result because the name as advertised puts other thoughts in people's minds. Not strictly part of the discussion, but a great example of how EJB has too many invisible features and what benefit we'd get by having these be explicit features only applied when action is taken. Worth mentioning for that reason alone.
Max Concurrency concepts. This one was discussed in EJB 3.1 and 3.2, Adam definitely championing that. Limiting threads is absolutely a way to get performance. One people do not typically acknowledge -- they often *add* threads to try and make things go faster. The question is where and how. In practice when there are many many independent limits in an app, it is near impossible to get them all to line up so things flow smoothly and one limit isn't too big causing a bottleneck on another limit that is too small. It is a feature that could be added cheaply, however, with an annotation on top of a interceptor that had a Semaphore underneath. If people had a way to use it only when they wanted it, it could be a useful service because the actual synchronization is something people often get wrong. Overall, I'd say it is low impact.
Pooled usage. Pooled is distinctly different than something like MaxConcurrency in my mind. MaxConcurrency could apply to a singleton for example -- that's arguably where it'd be most useful. Pooled would be when you don't want more than x instances created and we've all seen uses of that such as database pools where the thing being created is expensive. It's not a common situation, but when you need it there is really no other solution. In 2009-2010 range we actually rewrote all the instance pooling in OpenEJB because we had someone using it to hold GIS map data in each instance. Each map was about 100MB so there were real limits to how many could exist. They needed them there and ready, could not load them each request, but had to have tight control of how many there were due to resource constraints (memory). Not a common case, but as I say, when you need it you need it. Some form of generic pooling that could be applied to any resource hungry object could be very useful.
-David
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
