[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ee4j-community] Tomitribe commitment to EE4J
|
> On Oct 14, 2017, at 1:14 PM, Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
>
> Thanks for the insight David. Just to clarify my proposal on @MaxConcurrency: my 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.
Fully understood and agree. I think we're all on the same page. For some history:
- Here's where Adam brings up @MaxConcurrency. The thread diverts into @Asynchronous very quickly.
https://github.com/javaee/ejb-spec/issues/9
- Here's where Reza brings up @MaxConcurrency again and calls it out like you do as being distinctly different than pooling (and I agree)
https://github.com/javaee/ejb-spec/issues/113
The two are definitely separate.
> 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?
It's certainly tempting and that can definitely work. The plumbing for exposing a pooled resource via JCA is pretty intense.
In this particular user's case the logic to process each 100MB of map data was inside the @Stateless bean itself. They had a single ejb-jar.xml where they configured the same @Stateless bean class many times. Each declaration of the bean used a <env-entry> to initialize it with different regions. Each bean named each bean uniquely by geographical region and referenced by their application that way. It worked out well for them.
They could have done it via a resource adpater which they deployed N number of times, but it would have been significantly more painful and might not have eliminated the need to have N beans (business logic) uniquely named after each region.
Though, I am generally very pro JCA when it comes to connection pooling of any kind. I think you hit on something interesting linking bulkheads to JCA. This could be a standard QoS for a JCA adapter, just like connection pooling, and people could potentially leverage it generically regardless of what the resource is.
That's pretty darn brilliant. I think you hit some gold there. Jonathan Gallimore on our side is a huge JCA fan and I'm sure he's smiling ear to ear on that idea.
-David
