Personally I think you could just use JCache for this sort of
thing these days. That said, if this is deemed important enough,
one could introduce @Pooled or @PoolScoped. Concurrency might be
the best place for it.
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