[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ee4j-community] Tomitribe commitment to EE4J
|
Let's leave it alone. From my previous go at this, I am convinced discussing any of this in the CDI EG is a big waste of time.
I am sure all of it is fine in Java EE Concurrency. It's not too far fetched to think of pooling as an aspect of managing concurrently accessible resources.
Pooling has only very superficial similarities to bulkheads. The use cases as already explained by others is vastly different.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: "John D. Ament" <john.d.ament@xxxxxxxxx>
Date: 10/16/17 7:17 AM (GMT-05:00)
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Tomitribe commitment to EE4J
Reza,
Which *this* are you referring to? Pooled/PoolScoped?
At least one of my hopes is that CDI defines what the programming model looks like, not every feature of the programming model. For CDI to take on pooling for instance, means that the support of pooling comes from the CDI spec, which is effectively one of the problems faced by the EJB spec - it defined too much. CDI has already gone to far lengths to define this model, so I would hope its up to another spec to define how its used. This also works hand in hand with some of the other callouts I've seen on this list - modularity in particular.
In Eclipse MicroProfile, we may have defined that pooling replacement already. The classic example of a pool is effectively what is now coined as a bulkhead - limiting concurrent access to a single entry point. We have annotations that define the concurrent accessors of the bean. It hopefully shouldn't matter if its one instance or 10 instances to the caller, they all have to be modeled in a stateless fashion.
John
When I/others suggested this to the CDI EG in the past, they resisted for what seemed to me like non-technical reasons. Maybe they will change their mind this time and see reason. We can hope. Other than CDI, I don't even see where else @PoolScoped would fit.
I don't actually mind just throwing it in with the rest into Java EE Concurrency. What matters is making the functionality available to end users in the end.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
Date: 10/14/17 3:59 PM (GMT-05:00)
Subject: Re: [ee4j-community] Tomitribe commitment to EE4J
_______________________________________________
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