Cluster lifecycle events
by Kristoffer Sjögren
Hi
CDI 1.1 defines a set of lifecycle events related to different context
within the application, but we see a need to define cluster lifecycle
events for applications.
These events could, for example, be used for subscribing/allocating
and unsubscribing/deallocating external services/resources.
More specifically, a @Cluster event that gets fired when an
application gets @Initialized in the cluster, that is, post
@Application @Initialized. And another @Cluster event that gets fired
when the application get @Destroyed in the cluster, that is, pre
@Application @Destroyed. These events only fires once per application
and cluster, independent on how many cluster instances exists.
Events are fault tolerant meaning that events are not affected by
failing instances going out-of-service, as long as the cluster is
still working. Notice that the @Destroyed event is of course only
invoked if the cluster terminates gracefully.
Is this something you have considered earlier or is it worth
discussing/specifying further?
Cheers,
-Kristoffer
14 years, 9 months
Re: [cdi-dev] TransactionScope proposal
by Jonathan Halliday
As requested, some input from a transactions person...
>>>> The transaction context is provided by a built-in context object for the built-in scope type @TransactionScoped. The transaction scope is active when TransactionManager.begin is called (when the status goes to active), and ends when TransactionManager.commit or TransactionManager.rollback is called.
I assume you're making the simplifying assumption that
TransactionManager.suspend and TransactionManager.resume are off limits.
>>>> The transaction context is shared between all beans involved in the transaction. The transaction context is destroyed when transaction is rolledback, or committed.
Interesting things happen when a transaction hits timeout. The tx is (at
least in the case of JBossTS) rolled back on a background thread, but
the context on the 'business logic' thread running the tx is still
valid. That is to say, the context destruction is not necessarily
synchronous with the rollback. Unless you specify that it must be, in
which case you have fun issues with requiring that all code be
interruptible.
>>>> Design Notes: CDI transaction context could work with JTA by registering with a Synchronization callback with the Transaction object in JTA. Then CDI will listen for the STATUS_ACTIVE state to indicate a
transaction is active,
No such notification is generated by the JTA for Synchronizations.
You'll have to wrap TransactionManager.begin to generate that.
> STATUS_ROLLEDBACK to be notified of a rollback and lastly STATUS_COMMITTED to be notified of a commit.
Those are not the only valid terminal states for a transaction. You may
want to take account of heuristics too.
> The contextual instances will be stored directly or indirectly in the TransactionSynchronizationRegistry when STATUS_ACTIVE is handled, and removed when the STATUS_ROLLEDBACK or STATUS_COMMITTED is handled.
afterCompletion Synchronization calls are exactly that: *after*
Completion. There is no defined transaction context on the Thread any
longer at that point, so no access to TSR.[get|put]Resource. On the up
side, you don't explicitly need to clean up values stored via
TSR.putResource - once the tx object is garbage collected the store
associated with it goes away too.
Jonathan.
--
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)
14 years, 9 months
TransactionScope proposal
by Rick Hightower
*Section 2.4.1.*
TODO There are six standard scopes... (not five)
TODO (Then list @TransactionScope as one of those scopes.)
*Section 6.7.8 Transaction Context Lifecycle*
This should work with various types of transaction management systems, but
it is defined in terms of JTA for ease of documentation by associating it
with a known, specified JSR standard.
The transaction context is provided by a built-in context object for the
built-in scope type @TransactionScoped. The transaction scope is active when
TransactionManager.begin is called (when the status goes to active), and
ends when TransactionManager.commit or TransactionManager.rollback is
called.
The transaction context is shared between all beans involved in the
transaction. The transaction context is destroyed when transaction is
rolledback, or committed.
An event with the TransactionEvent as payload and with qualifier
@Initialized(TransactionScoped.class) is fired when the transaction context
is initialized and moved to the active state and an event with qualifier
@Destroyed(TransactionScoped.class) when the transaction context is
destroyed.
Design Notes: CDI transaction context could work with JTA by registering
with a Synchronization callback with the Transaction object in JTA. Then CDI
will listen for the STATUS_ACTIVE state to indicate a transaction is active,
STATUS_ROLLEDBACK to be notified of a rollback and lastly STATUS_COMMITTED
to be notified of a commit. The contextual instances will be stored directly
or indirectly in the TransactionSynchronizationRegistry when STATUS_ACTIVE
is handled, and removed when the STATUS_ROLLEDBACK or STATUS_COMMITTED is
handled.
If a transaction is suspended, the transactional scoped data is not
impacted. It is only the transaction active status or its final state of
committed or rolledback that impacts the lifecycle of the CDI transaction
context.
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
14 years, 9 months
calling 'equals' on a proxy?
by Mark Struberg
Hi Pete, others!
Do you remember our discussion about what should happen if equals() gets called on a proxy?
Should it route to the equals method of the currently proxied instance?
LieGrue,
strub
14 years, 10 months
Question for clarification and my understanding
by Rick Hightower
Section 5.4
"Client proxies are never required for a bean whose scope is a pseudo-scope
such as @Dependent."
I understand the concept of client proxies to allow for scopes and context.
Is this a true statement...
Client proxies may not be needed for @Dependent (pseudo scope). CDI may
provide a client proxy for @Dependent.
A proxy is needed for @Dependent objects that are decorated or intercepted
with Decorators or Interceptors.
Are all injected objects proxied or only objects that are normal scoped or
decorated?
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
14 years, 10 months
Bean Metadata section 5.5.8
by Rick Hightower
a bean with scope @Dependent, qualifier @??? and type Bean which can be
injected into any decorator instance
• a bean with scope @Dependent, qualifier @??? and type Bean which can be
injected into any interceptor instance These beans are passivation capable
dependencies, as defined in Section 6.6.2, “Passivation capable
dependencies”.
I guess this is an open Jira issue.
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
14 years, 10 months
5.5. Dependency injection
by Rick Hightower
Section 5.5
*5.5. Dependency injection*
...
"A Java EE 5 container is not required to support injection for
non-contextual objects."
Prior to this sentence it just listed all of the non-contextual objects that
it had to support.
We should either drop the sentence, or clarify it.
"A Java EE 5 container is not required to support injection for
non-contextual objects not already mentioned above."
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
14 years, 10 months
