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.