Hello Rainer, others,
>> 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?]
> Actually, I would believe that inheritance based on the actual
> transaction participation with divergent defined state might be a bit
> confusing.
Similar to my comment on the Open Issue, allowing inheritance of Extended PCs into components requiring different transactional participation will be problematic as those PCs will be bound to those components which could result in a SYNC'd PC being bound to a component requiring an UNSYC'd PC.
Propagation of Transaction scoped PCs with different transactional requirements would be ok but specifying the different use-cases may be confusing.
--Gordon
On 9/6/2011 12:30 PM, Rainer Kwesi Schweigkoffer wrote:
> Hi Linda, all,
>
> Linda DeMichiel, am 26 Aug 2011 hast Du um 12:00 zum Thema "[jsr338-experts] unsynchronized persistence conte" geschrieben :
>
>> Proposal:
> [..]
>
>
>> 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.
> Would add an "if extended" or something alike here for clarity.
>
>
>> 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.
> I'd also go for a TRE here.
>
>> 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.
> Could you work out a bit more on this ?
>
>> 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?]
> Actually, I would believe that inheritance based on the actual
> transaction participation with divergent defined state might be a bit
> confusing.
>
> Best regards
> Rainer
>
>
>
> ---
> Rainer Schweigkoffer SAP AG Walldorf
> Business Solution& Technology TD Core JS&I
> Technology Development Dietmar-Hopp-Allee 16
> Java Server Core D-69190 Walldorf
> JEE Implementation Group phone: +49 6227 7 45305
> Building 3, I.3.14 fax: +49 6227 7 821177
> rainer.schweigkoffer_at_sap.com
>
> Sitz der Gesellschaft/Registered Office: Walldorf, Germany
> Vorstand/SAP Executive Board: Werner Brandt, Angelika Dammann,
> Bill McDermott (Co-CEO), Gerhard Oswald, Vishal Sikka,
> Jim Hagemann Snabe (Co-CEO)
> Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory
> Board: Hasso Plattner
> Registergericht/Commercial Register Mannheim No HRB 350269
>
> Diese E-Mail kann Betriebs- oder Geschaeftsgeheimnisse oder sonstige
> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
> irrtuemlich erhalten haben, ist Ihnen eine Verwertung des Inhalts,
> eine Vervielfaeltigung oder Weitergabe der E-Mail ausdruecklich
> untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die
> empfangene E-Mail. Vielen Dank.
>
> This e-mail may contain trade secrets or privileged, undisclosed, or
> otherwise confidential information. If you have received this e-mail
> in error, you are hereby notified that any review, copying, or
> distribution of it is strictly prohibited. Please inform us
> immediately and destroy the original transmittal. Thank you for your
> cooperation.
>
>