On Oct 29, 2024, at 11:36 AM, Reza Rahman via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx> wrote:
Instance pooling is another outdated artifact of the past. It was
more necessary in the early days when the JVM was not efficient at
garbage collection. These days it's simply overkill.
It's absolutely correct that the original motivation for instance pooling is no longer relevant. Reza knows, but for those that weren't around in the early days the motivation was that creating and destroying java objects was expensive. This was fixed at the JVM level around Java 1.2.
Where I've seen this used in recent years is just pooling in general for any expensive resource. They create a stateless bean that holds and encapsulates one "instance" of the expensive resource. The EJB spec has the whole check-in / check-out mechanism built in, then they rely on the pooling config of the container to set the min and max number of instances.
One of the most compelling I've seen is one of the global leaders in GIS data use it to manage map data in memory. They had a DCOM object associated with a specific region and each region represented a few hundred MB of memory, so they had to be managed very very carefully.
-David
On 10/29/2024 11:42 AM, Bauke Scholtz
via jakarta.ee-community wrote:
Hi,
> I did not understand why EJB Containers have this
pooling mechanism.
EJB instances are basically synchronized. This is
unnecessary for stateless beans so they introduced pooling.
CDI instances are basically unsynchronized. So pooling is
unnecessary.
I took a look on the tutorial form Bauke and I
wonder if I understand your recommendations
correctly?
The first example shows a stateless EJB with the
@Stateless annotation. In the CDI variant you use
the @ApplicationScoped annotation. I have seen
this often in other code examples.
But I wonder if this annotation is a good or
equivalent solution? From my understanding the
@ApplicationScoped annotation is a singleton
pattern.
But a stateless EJB uses the Container pool
mechanism. Which means the EJB application can use
many beans in parallel. But the CDI application
can only serve the requests from one single CDI
Bean.
Or am I totally wrong here?
===
Ralph
On 29.10.24 13:35, Bauke Scholtz via
jakarta.ee-community wrote:
Hi,
> Are there any comprehensive tutorials
on how to utilize CDI rather than EJB for
querying entities? It seems like these
tutorials need to be made front and center in
an effort to help steer people to CDI and to
show that EJB is no longer needed in many
cases.
I agree. I think we need to
clarify the problem with EJB. Is it
technical, as in there's a lot of
baggage/fat that simply cannot be shed
without completely killing the tech?
Especially from an implementation
perspective?
Or is it more a problem of perception,
where a whole generation of developers
have grown up hearing nothing but horror
stories from the days of entity beans and
thus, would want to steer clear of EJB and
consequently, the platform itself?
Personally I lean towards "spring
cleaning" the internals of EJBs if it's a
problem of the former and leaving the
technology alone.
Why? Because it just works. A single
annotation does a lot of heavy lifting on
my behalf. And that is cool. It's also
easy to teach newcomers.
From a business perspective, I'd ask,
which would add more weight to portraying
the platform as modernising?
A test spec/attempt to standardize
consuming AI on the platform?
Or killing EJBs?
If the goal is to portray the platform
as alive and modernising, I think nothing
is more a testament than an incubator spec
that taps into arguably the most hyped
tech of our time?
We may have different views of the
whole AI stuff, but if Spring already has
Spring AI, Quarkus has native integration
with LangChaing4J, where's Jakarta?
So though EJB may be a polarising tech
depending on who you speak with, I think
if the goal of EE 12 is to show that it's
still a technology that is evolving with
the times, then our target lies elsewhere.
I also think that until
now, EJBs are not fully replacable with
other Jakarta EE constructs. And thus we
shouldn’t try to hide EJBs from
developers learning Jakarta EE. In fact,
teaching developers about EJBs
simplifies things a lot. With just a
single @Stateless or @Songleton
annotation they get transactions
automatically, can easily define timers,
concurrency is handled (no state should
be in stateless, singletons are
syncrhonized).
Yes, it’s possible to
rewrite EJBs with other constructs but
the resulting code is much more verbose
and easy to get wrong - timers in
Concurrency require to call a method to
trigger them, running a method on
startup is more verbose compared to
@Startup on a singleton EJB,
ApplicationScoped CDI beans are not
thread safe unlike Singleton EJBs,
@RolesAllowed only works on EJBs and not
CDI beans, etc.
Jakarta EE still needs
improvements to fully replace EJB. And
even then it would be good to have a
single CDI annotation to enable all the
features of EJB in a CDI bean. Until
then, it’s better to teach EJBs and then
explain how to use the new concepts in
Jakarta EE to avoid EJBs for advanced
developers.
I completely agree with that. EJBs
are not bad per se and should not be
abandoned.
Everyone is free to use them or not.
Best regards,
Bernd
Am 28.10.24 um 14:54 schrieb Ralph
Soika via jakarta.ee-community:
> Hello,
>
> I became aware of this
discussion through the topic "EJB
-> CDI migration" and would like
to briefly
> share my thoughts about it.
> My fear here is to "ban" EJBs
as something outdated, complicated
and unnecessary. But is that right?
> I myself run with imixs.org
<https://www.imixs.org>
a very large Jakarta EE project. And
my opinion
> is that you should always
implement the DataAccessLayer as
also complex ProcessingServices in a
> stateless EJB in order to make
use of the transaction capability.
> I do know that you can also use
CDI for data access. But is it the
same?
>
> For example in my own project
(a BPMN workflow engine) the
DataAccess Service as also the
Engine
> itself is implemented as a
stateless EJB.
> A project that is using the
library just need to inject the
WorkflowEngine. The user does not
have
> to think about transactions or
EJBs at this moment. The app
developer can now extend the engine
> behavior by implementing so
called 'Plug-Ins' as simple CDI
beans. Such a CDI bean is a kind of
> adapter class that can for
example react on specific CDI Events
in the processing life-cycle. And of
> course the developer can again
inject the DataService form the
Workflow Engine to create new data.
>
> The point is that if something
goes totally wrong, the default
transaction manager takes care about
> the rollback over all layers.
>
> And this all comes for free
just because of using the stateless
local EJB pattern. For the developer
> there is no need to think about
EJBs at all.
>
> I may be wrong here, but I
would always advise a developer to
implement the data access layer via
> EJBs to keep the rest of the
application as lean as possible.
> Therefore, in my opinion, EJBs
play an important role. A tutorial
should not hide its concepts.
>
> Best regards
>
> Ralph
>
> On 28.10.24 14:21, Reza Rahman
via jakarta.ee-community wrote:
>> I think the Tutorial
refactoring work could easily be
tagged “good first issue” and “help
wanted”.
>> We have a shockingly low
number of those across EE4J
projects.
>>
----------------------------------------------------------------------------------------------------
>> *From:* Kito Mann <kito.mann@xxxxxxxxxxx>
>> *Sent:* Sunday, October 27,
2024 11:50 PM
>> *To:* jakarta.ee-spec@xxxxxxxxxxx
<jakarta.ee-spec@xxxxxxxxxxx>;
Jakarta EE community discussions
>> <jakarta.ee-community@xxxxxxxxxxx>;
jakarta.ee-marketing@xxxxxxxxxxx
<jakarta.ee-
>> marketing@xxxxxxxxxxx>;
Reza Rahman <reza_rahman@xxxxxxxx>
>> *Cc:* Jakarta EE
Ambassadors <jakartaee-ambassadors@xxxxxxxxxxxxxxxx>;
juneau001@xxxxxxxxx
>> <juneau001@xxxxxxxxx>;
Kito Mann <kito.mann@xxxxxxxxxx>
>> *Subject:* Re: EJB ->
CDI migration (was Re: Defining
Jakarta EE 12 Scope in Program Plan)
>> I love all three of these
ideas:
>>
>> 1. EJB -> CDI Migration
Guide
>> 2. New EJB -> CDI
Migration talk
>> 3. Updating the Jakarta EE
Tutorial to remove EJB when possible
>>
>> (3) is non-trivial since a
lot of work needs to be done
upgrading/rewriting the examples in
>> general, but that doesn’t
mean I can’t at least break that
work down into the issue
tracker. Also,
>> the intro (which I rewrote)
specifically does not mention EJB.
>>
>> I’d like to add another:
Writing an OpenRewrite for
migrating from EJB->CDI.
>>
>> ___
>>
>> Kito D. Mann <https://kitomann.com> |
@kito99@mastodon.social <https://mastodon.social/@kito99>|
>> LinkedIn <https://www.linkedin.com/in/kitomann/>
>> Java Champion | Google
Developer Expert Alumni
>> Expert consulting and
training: Cloud architecture and
modernization, Java/Jakarta EE, Web
>> Components, Angular, Mobile
Web
>> Virtua, Inc. | virtua.tech
<http://virtua.tech>
>> +1 203-998-0403
>>
>> * Enterprise development,
front and back. Listen to Stackd
Podcast <http://stackdpodcast.com/>.
>> * Speak at conferences?
Check out SpeakerTrax <https://speakertrax.com>.
>> On Oct 27, 2024 at 2:46 PM
-0400, Reza Rahman <reza_rahman@xxxxxxxx>,
wrote:
>>
>> I am moving comments on
my Jakarta EE 12 Google Doc
>> (https://docs.google.com/document/d/1U2qEqF9K969t5b3YuX4cwex5LJPvF3bt1w27cdKNpDM/edit?usp=sharing)
>> to Jakarta EE mailing
lists when possible. The problem
with Google Docs
>> comments is that they
do not scale very well, aren't very
readable on
>> smaller devices, and do
not archive well. I will do so one
email per
>> comment. The person
commenting is copied.
>>
>> Context: Why does
replacing EJB matter?
>>
>> Josh Juneau
(Community): Are there any
comprehensive tutorials on how to
>> utilize CDI rather than
EJB for querying entities? It seems
like these
>> tutorials need to be
made front and center in an effort
to help steer
>> people to CDI and to
show that EJB is no longer needed in
many cases.
>>
>> Reza Rahman
(Microsoft): Good point. As of
Jakarta EE 11, it is indeed
>> possible to just use
CDI now for basic CRUD in a
transactional and
>> thread safe manner with
Jakarta Persistence. The same for
EJB
>> @Asynchronous and
@Schedule. At the bare minimum, this
is worthy of an
>> Eclipse Foundation
newsletter article and/or JakartaOne
talk. The
>> material could cover
where EJB is not needed any more and
where it is
>> still needed. The title
could be something attention
grabbing like -
>> "EJB is Dead, Long-Live
CDI and Jakarta EE". We could also
ensure a
>> revised Jakarta EE 11
Tutorial can avoid using EJB when
possible. Maybe
>> Kito could comment on
this? Additionally, the Marketing
Committee has
>> been sponsoring some
guides. Could we consider already
starting an EJB
>> migration guide?
>>
>> On 10/22/2024 5:30 AM,
Reza Rahman wrote:
>>
>> Hi folks,
>>
>> I would like to see
if we can define clear, compelling,
and specific
>> scope for Jakarta
EE 12 as part of the Steering
Committee Program
>> Plan:
>> https://docs.google.com/presentation/d/1xUNDHMP_qTHH1wA3m0yCmWVf_sHp41Qd7Opq3FhgINs/edit?
>> usp=sharing.
>> I believe this is
of critical importance at this
juncture. If I did
>> not think so, I
would not bother trying. I have
detailed all the
>> rationale here:
>> https://docs.google.com/document/d/1U2qEqF9K969t5b3YuX4cwex5LJPvF3bt1w27cdKNpDM/edit?
>> usp=sharing.
>> For those that
recall, something very similar was
done for Jakarta EE
>> 11, so this isn't
exactly without precedent.
>>
>> I would like to see
if this can be done in the following
couple of
>> weeks, when the
Program Plan is due.
>>
>> Thanks,
>>
>> Reza
>>
>>
>> Reza Rahman
>>
>> Principal Program Manager
>>
>> Java on Azure at Microsoft
>>
>> reza.rahman@xxxxxxxxxxxxx
>>
>> +1 717 329 8149
>>
>>
>>
_______________________________________________
>> jakarta.ee-community
mailing list
>> jakarta.ee-community@xxxxxxxxxxx
>> To unsubscribe from this
list, visithttps://www.eclipse.org/mailman/listinfo/jakarta.ee-community
> --
>
> *Imixs Software Solutions GmbH*
> *Web:* www.imixs.com
<http://www.imixs.com>
*Phone:* +49 (0)89-452136 16
> *Timezone:* Europe/Berlin -
CET/CEST
> *Office:* Frei-Otto-Str. 4,
80797 München
> Registergericht: Amtsgericht
München, HRB 136045
> Geschäftsführer: Gaby Heinle u.
Ralph Soika
>
> *Imixs* is an open source
company, read more: www.imixs.org
<http://www.imixs.org>
>
>
>
_______________________________________________
> jakarta.ee-community mailing
list
> jakarta.ee-community@xxxxxxxxxxx
> To unsubscribe from this list,
visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Prof. Dr. Bernd Müller
Ostfalia
Hochschule für angewandte
Wissenschaften
- Hochschule
Braunschweig/Wolfenbüttel -
Fakultät Informatik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel
_______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
