users@ejb-spec.java.net

[ejb-spec users] Re: Transactional _at_Singleton _at_Startup lifecycle

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Wed, 25 Jan 2017 13:53:17 -0800

Hello Stefan,

For a Startup Singleton session bean that uses container-managed
transactions for the PostConstruct method, the container will wrap the
invocation of the method with the transaction - i.e., the transaction
will be started before the PostConstruct method is invoked and
completed after the invocation of the PostConstruct method has
completed.

Section 4.8.1 states that any client invocations (i.e., business method
invocations) must not be delivered to the bean until the startup
completes. The container's invocation of the PostConstruct method
is considered as part of the bean's initialization, and is not a
client request.

What behavior are you seeing? Is the message to the queue not being
published at all, or is it only published after the PostConstruct
method has completed (which is the behavior that should occur).

-Linda


On 1/13/17 3:22 PM, Stefan Zwanenburg wrote:
> Hello everyone,
>
> Let me start off by saying I can't pretend to understand the entirety of
> the EJB specifications. Despite this, I've found myself in a bit of a bind.
>
> A short description of said bind: we use the container product of one of
> the members of the expert group developing this spec, and I believe it
> to not be fulfilling one of its responsibilities. In particular the way
> in which it handles @Startup singletons. What I have is one such
> singleton, and within its @PostConstruct callback, it publishes a
> message to a queue, and it does this transactionally. This works when I
> deploy the singleton on a running container, as that means all it needs
> to complete the transaction is up and running. However, if I restart the
> container, it'll run the @PostConstruct callback before being able to
> commit the transaction successfully.
>
> Now, I've been looking at the section of the spec pertaining to
> transactions in relation to these lifecycle callbacks, and my takeaway
> is that the container ought to support my usecase.
> My question to you, then, is this: is that indeed the intent behind
> section 4.8.3? If it is, is it possible that section 4.8.1 gives just a
> bit too much leeway to the implementation when it says:
> The container must initialize all such startup-time singleton
> session beans before any external client requests (that is, client
> requests originating outside of the application) are delivered to any
> enterprise bean components in the application.
> To me, it's not entirely clear if my usecase and that but of text are at
> odds with one another. Is a transaction an "external client request"?
>
> I could not find a test case in the source repository for this
> particular case. Is it left up to the interpretation of the implemented
> whether or not my case should be supported?
>
> Thanks for reading this far, and thanks in advance for taking the time
> to send me a reply!
>
> Stefan Zwanenburg