| Re: [jakartaee-platform-dev] Question about meaning of `initialize-in-order` when application deployment may be multi-threaded... |
Scott,
I think the original purpose of <initialize-in-order>was to provide order where none was previously defined. The module initialization was (and still is) undefined back in Java EE 5/6 days. By introducing this element, the user has some control over the ordering of the module initialization for their application. A common usage was to initialize some database tables with an early initialized module and then these would be ready for use by the later modules.
Thanks for the response Kevin!
From the wording used for [1], it sounds like the only guarantee
is the order that modules are initialized in but what I am trying
to better understand, is the impact on multi-threaded deployment
aspects of things that might deploy more quickly in a different
thread (like persistence units which might be initialized in a
different thread than the EE module itself). IMO, the vague
aspect of [1] is whether all EE deployment elements are also
initialized in the exact specified (module name) order.
I wonder how many EE implementations are using a single deployment thread to handle deploying the various modules + all of the EE elements referenced from each module? Even if they are, WildFly is still deploying persistence units from different threads, so I'm also questioning what application writers can expect currently with regard to `initialize-in-order`.
For example, if an application includes 2 EJB sub-modules (ejb1 + ejb2) that each contain persistence units based on entity classes that are shared across the (initialize-in-order=true) EAR , can application developers expect to use the various persistence units from any sub-deployment? From a Persistence specification perspective, I think yes but from a practical view, that might not work for all EE implementations.
In other words, `initialize-in-order` [1] handling doesn't really
seem to consider multi-threaded EE deployment which leads to my
above question about what application developers should really
expect when using this feature on the various EE implementations.
Since it's defined by the spec, I bet most (all?) of the major implementations provide this functionality. But, since these implementations also most likely provide their own deployment mechanisms, they probably also provide other mechanisms to control the ordering of module initialization. Does the TCK have tests for this element?
The TCK does have some tests with `initialize-in-order` that I
think are just testing that modules start being initialized in the
specified order (IMO, as if a single thread was controlling the
start of each module deployment). I don't think those tests are
verifying that non-modules elements (e.g. persisatence units) are
also initialized in a particular order.
Scott
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
From: "Scott Marlow" <smarlow@xxxxxxxxxx>
To: "jakartaee-platform developer discussions" <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 08/03/2021 15:59
Subject: [EXTERNAL] [jakartaee-platform-dev] Question about meaning of `initialize-in-order` when application deployment may be multi-threaded...
Sent by: "jakartaee-platform-dev" <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
Hi,
I am trying to understand the original purpose of `initialize-in-order` [1] which seems likely to be implementation specific. It is pretty clearly written to assume that top/sub modules are deployed in a specific ordering that the user specifies but there are no Jakarta EE Platform requirements that a single deployment thread is used, so its not really clear how [1] should be accomplished when multiple threads are used for deployment.
Do any EE implementations that handle deployment via multiple threads also support `initialize-in-order` [1] controlling the order that the multiple threads deploy each (sub)module in?
Scott
[1] https://jakarta.ee/specifications/platform/8/platform-spec-8.html#a3201_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev