Hi Adam,
On 9/9/2011 4:16 AM, Adam Bien wrote:
>
> On 08.09.2011, at 22:45, Evan Ireland wrote:
>
>> Linda,
>>
>> You wrote:
>>
>>> I think that binding EPCs to singletons is potentially
>>> useful; inheritance
>>> not so much.
>>
>> I'm not sure that I agree. The primary use case that I am aware of for EPC's
>> is for session-related persistence.
>>
>> If someone can give a use case for the use of EPC's with singletons, I would
>> like to hear it.
>
> I would allow the propagation from a SFSB to SLSB or even Singletons Beans in a call stack (=ThreadLocal).
> IMHO it would feel natural.
Propagation, yes. I was concerned about "inheritance".
>>
>>> -----Original Message-----
>>> From: Linda DeMichiel [mailto:linda.demichiel_at_oracle.com]
>>> Sent: Friday, 9 September 2011 6:44 a.m.
>>> To: jsr338-experts_at_jpa-spec.java.net
>>> Cc: Gordon Yorke
>>> Subject: [jsr338-experts] Re: unsynchronized persistence contexts
>>>
>>> At this point, I think the safest course of action here is
>>> the conservative
>>> one, and not to proceed with changes to the inheritance
>>> rules, at least
>>> until we get further feedback in this regard.
>>>
>>> If you feel strongly about this issue, please let me know.
>>>
>>> I have also been thinking about singletons, which were left as an open
>>> issue in the proposal I circulated.
>>>
>>> Inheritance of PCs by singleton's is also problematic, independent of
>>> whether they are synchronized or not.
>>> The EJB spec states that singleton's are created by the container,
>>> not directly by the application. This creation may be at startup
>>> (and is required to be if the @Startup annotation has been applied),
>>> or it may be deferred, as late as the first method invocation upon
>>> the singleton. The time of the creation of a singleton is also
>>> influenced by whether any other singleton has a @Depends relationship
>>> upon it.
>>>
>>> We thus cannot assume that a singleton that is not marked @Startup
>>> should inherit a PC (as the rules below proposed for method invocation
>>> time inheritance for SLSBs), as that singleton may have been created
>>> at startup time as well. So, my conclusion is that a singleton should
>>> not inherit a PC.
>>>
>>> That leaves the issue of whether EPCs should be bound to singletons,
>>> and, if so, whether such EPCs should be inherited by beans which
>>> the singleton instantiates.
>>>
>>> I think that binding EPCs to singletons is potentially
>>> useful; inheritance
>>> not so much.
>>>
>>> Should we extend the notion of *binding* an EPC to a singleton??
>>>
>>> -Linda
>>>
>>>
>>> On 9/2/2011 7:05 AM, Gordon Yorke wrote:
>>>>> Subject to the above requirements, a synchronized
>>> persistence context
>>>>> or an unsynchronized persistence context may be propagated into a
>>>>> component that specifies an unsynchronized persistence context. An
>>>>> unsynchronized persistence context may only be propagated into a
>>>>> component that specifies an unsynchronized persistence context. The
>>>>> attempt to propagate an unsynchronized persistence context into a
>>>>> component that specifies a synchronized persistence
>>> context causes the
>>>>> EJBException to be thrown. [OPEN ISSUE: Is this the right
>>> exception?
>>>>> Should we relax this if the PC has been joined to the transaction?]
>>>> Hello All,
>>>> I have been thinking about this issue for a while and
>>> believe it is unsafe to allow a *joined* EXTENDED UNSYNC'd PC
>>>> to be *inherited* by a component using a SYNC'd PC. The
>>> UNSYNC'd PC would become bound to that component and that would
>>>> be technically incorrect. We could allow the propagation
>>> of *joined* TRANSACTION UNSYNC'd PCs to SYNC'd PCs but that
>>>> may be too confusing for users.
>>>>
>>>> On 8/26/2011 4:00 PM, Linda DeMichiel wrote:
>>>>>
>>>>> When we solicited feedback on features for this release, one of the
>>>>> discussions on the jsr-317 feedback list concerned the ability to
>>>>> specify a persistence context that was not "synchronized"
>>> with regard
>>>>> to transactions -- i.e., which did not respond to transaction
>>>>> synchronization notifications. This would offer a cleaner
>>> alternative
>>>>> to the manual flushmode which was decisively rejected by
>>> the JPA 1.0
>>>>> expert group.
>>>>>
>>>>> JPA already has the notion of a persistence context that is
>>>>> unsynchronized. This occurs when an application-managed
>>> persistence
>>>>> context is created outside the scope of a JTA transaction, and the
>>>>> application must notify the entity manager that the persistence
>>>>> context is to be joined to a subsequently-started
>>> transaction by means
>>>>> of the joinTransaction() method.
>>>>>
>>>>> The proposal below is a strawman proposal for unsynchronized
>>>>> container-managed persistence contexts that Mike, Gordon,
>>>>> and I have collaborated on.
>>>>>
>>>>> This proposal attempts to define synchronization as
>>> orthogonal to the
>>>>> existing persistence context types and propagation rules.
>>> It loosens
>>>>> some of the restrictions imposed by those types however.
>>>>> In particular:
>>>>> -- Entity managers for unsynchronized transaction-scoped
>>> persistence
>>>>> contexts can be used to invoke the persist, remove,
>>> refresh, and
>>>>> merge operations regardless of the presence of an
>>> existing transaction.
>>>>> -- The notion of extended persistence context is loosened
>>> to include
>>>>> the use of extended persistence contexts being "bound"
>>> to stateless
>>>>> session beans in order to capture the ability to
>>> propagate extended
>>>>> persistence contexts from stateful session beans to stateless
>>>>> session beans outside of a transaction.
>>>>>
>>>>> Please post your feedback to the group, including on the
>>> open issues.
>>>>>
>>>>> thanks,
>>>>>
>>>>> -Linda
>>>>>
>>>>> -----------------------------------
>>>>>
>>>>> Proposal:
>>>>>
>>>>> A container-managed persistence context can be designated
>>> at its point
>>>>> of creation to be unsynchronized by means of the synchronization
>>>>> element of the PersistenceContext annotation. Both
>>> transaction-scoped
>>>>> and extended persistence contexts may be designated as
>>> unsynchronized.
>>>>>
>>>>> @Target({TYPE, METHOD, FIELD}) @Retention(RUNTIME)
>>>>> public @interface PersistenceContext {
>>>>> String name() default "";
>>>>> String unitName() default "";
>>>>> PersistenceContextType type default TRANSACTION;
>>>>> SynchronizationType synchronization default SYNCHRONIZED;
>>>>> PersistenceProperty[] properties() default {};
>>>>> }
>>>>>
>>>>> public enum SynchronizationType {
>>>>> SYNCHRONIZED,
>>>>> UNSYNCHRONIZED
>>>>> }
>>>>>
>>>>> A persistence context of type UNSYNCHRONIZED is not enlisted in any
>>>>> JTA transaction unless explicitly joined to that transaction by the
>>>>> application.
>>>>>
>>>>> An unsynchronized persistence context is enlisted in a JTA
>>> transaction
>>>>> and registered for subsequent transaction notifications
>>> against that
>>>>> transaction by invoking the EntityManager joinTransaction() method.
>>>>> The persistence context remains joined to (synchronized with) the
>>>>> transaction until the transaction commits or rolls back. After the
>>>>> transaction commits or rolls back, the persistence context
>>> will not be
>>>>> synchronized with any subsequent transaction unless the
>>> joinTransaction
>>>>> method is invoked in the scope of that subsequent transaction.
>>>>>
>>>>> A persistence context of type
>>> SynchronizationType.UNSYNCHRONIZED must
>>>>> not be flushed to the database unless it is joined to a
>>> transaction.
>>>>> Both the persistence provider and the application are
>>> prohibited from
>>>>> flushing to the database until the point that a
>>> transaction has been
>>>>> joined. The application's use of queries with pessimistic
>>> locks, bulk
>>>>> updates/delete queries, etc. result in the provider throwing the
>>>>> TBDException. (If the application has specified FlushMode.AUTO, it
>>>>> must be ignored by the provider when executing queries.)
>>> [Open Issue:
>>>>> should this be IllegalStateException or a new JPA
>>> exception?] After
>>>>> the persistence context has been enlisted in the JTA transaction,
>>>>> these operations are again allowed.
>>>>>
>>>>> The application is permitted to invoke the persist, merge,
>>> remove, and
>>>>> refresh entity lifecycle operations on an entity manager
>>> corresponding
>>>>> to a unsynchronized transaction-scoped persistence context
>>> as well as
>>>>> one corresponding to an unsynchronized extended persistence context
>>>>> independent of whether a transaction is active.
>>>>> Such changes in the persistence context can be flushed to
>>> the database
>>>>> either explicitly by the application or by the provider after the
>>>>> persistence context has been joined to a transaction. If
>>> flush() is
>>>>> not explicitly invoked, flushing may be deferred until commit time
>>>>> depending on the operations invoked (and the setting of
>>>>> FlushModeType.)
>>>>>
>>>>> If an unsynchronized persistence context has not been joined to the
>>>>> current JTA transaction, rollback of the JTA transaction
>>> will have no
>>>>> effect upon the persistence context. It is recommended that the
>>>>> persistence provider use a non-JTA datasource for an unsynchronized
>>>>> persistence context that has not been joined to a JTA
>>> transaction to
>>>>> alleviate the risk of integrating uncommitted changes into the
>>>>> persistence context in the event that the transaction is
>>> later rolled
>>>>> back.
>>>>>
>>>>> If an unsynchronized persistence context has been joined to the JTA
>>>>> transaction, transaction rollback will cause the
>>> persistence context
>>>>> to be cleared and all pre-existing managed and removed instances to
>>>>> become detached. (See spec section 3.3.2.)
>>>>>
>>>>> When a JTA transaction exists, an unsynchronized
>>> persistence context
>>>>> is propagated with that transaction according to the rules
>>> below (in
>>>>> the section Requirements for Persistence Context Propagation)
>>>>> regardless of whether the persistence context has been
>>> joined to that
>>>>> transaction.
>>>>>
>>>>>
>>>>> Container-managed Extended Persistence Contexts (See spec section
>>>>> 7.6.2)
>>>>>
>>>>> The rules pertaining to extended persistence contexts are
>>> relaxed as
>>>>> follows: Any EJB component may specify the use of an extended
>>>>> persistence context. If the persistence context bound to
>>> a stateful
>>>>> session bean is not inherited by any other component, it is the
>>>>> responsibility of the container to close the persistence
>>> context when
>>>>> the @Remove method of the stateful session bean completes (or the
>>>>> stateful session bean instance is otherwise destroyed) or when the
>>>>> method invocation completes (if the component is a
>>> stateless session
>>>>> bean or message-driven bean). [OPEN ISSUE: still need to
>>> handle the
>>>>> singleton session bean case.]
>>>>>
>>>>>
>>>>> Inheritance of Extended Persistence Contexts (See spec section
>>>>> 7.6.2.1.)
>>>>>
>>>>> If a component to which an extended persistence context is bound
>>>>> instantiates a stateful session bean component (executing
>>> in the same
>>>>> EJB container instance), which also specifies an extended
>>> persistence
>>>>> context, the extended persistence context of the first component is
>>>>> inherited by the second component and bound to it, and this rule
>>>>> recursively applies--independent of whether transactions
>>> are active or
>>>>> not at the point of the creation. If the second component is a
>>>>> stateless session bean component that is invoked by a component to
>>>>> which an extended persistence context is bound, the persistence
>>>>> context is propagated into the that stateless session bean
>>> and bound
>>>>> to it for the duration of the method invocation.
>>>>>
>>>>> If the persistence context has been initiated or inherited by any
>>>>> stateful session bean, the container does not close the persistence
>>>>> context until all such stateful session beans have been removed or
>>>>> otherwise destroyed.
>>>>>
>>>>>
>>>>> Requirements for Persistence Context Propagation
>>>>> (See section 7.6.3.1)
>>>>> All the requirements of section 7.6.3.1 still apply. (The word
>>>>> "existing" in the second sub-bullet should be removed.)
>>>>> In addition, the following is added to the last bullet point:
>>>>>
>>>>> Subject to the above requirements, a synchronized
>>> persistence context
>>>>> or an unsynchronized persistence context may be propagated into a
>>>>> component that specifies an unsynchronized persistence context. An
>>>>> unsynchronized persistence context may only be propagated into a
>>>>> component that specifies an unsynchronized persistence context. The
>>>>> attempt to propagate an unsynchronized persistence context into a
>>>>> component that specifies a synchronized persistence
>>> context causes the
>>>>> EJBException to be thrown. [OPEN ISSUE: Is this the right
>>> exception?
>>>>> Should we relax this if the PC has been joined to the transaction?]
>>>>>
>>>>>
>>>>>
>>>
>>
>
>