jsr338-experts@jpa-spec.java.net

[jsr338-experts] Re: updated spec draft: unsynchronized persistence contexts

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Mon, 14 Nov 2011 15:22:44 -0800

Hi Rainer, all,

More below....

On 11/11/2011 5:08 AM, Rainer Kwesi Schweigkoffer wrote:
> Hi Linda, all,
>
> please find my comments below.
>
> Am 8 Nov 2011 um 17:01 hat Linda DeMichiel geschrieben:
>
>> I've uploaded a new specification draft to the project Documents area
>> (http://java.net/projects/jpa-spec/downloads)
>>
>> This draft includes changes in support of unsynchronized persistence
>> contexts along the lines of the proposal submitted two months ago.
>>
>> These changes affect Chapters 3 and 7 and section 10.4.1. There are a
>> number of open issues flagged in the text, including some pertaining
>> to ways in which we might extend this functionality.
>
>
>
> 3.1.1 1st paragraph 1st sentence, p. 76 :
>
> There seems a verb to be missing in the when clause.
>

Now fixed.

>
>
> 3.1.1 3rd paragraph, p. 76& 3.8.7 4th paragraph after the bullets,
> p. 130 :
>
> Actually, I am missing the basic statement here that, when being
> joined to a transaction, the resulting entities are managed. Too
> clear to say ?
>

Yes, I think so :-)

>
> 3.3.1, p. 85& 10.4.1, p. 389& others :
>
> To my understanding, the synchronisation type of an application-
> managed persistence context is determined by the circumstances of its
> creation; only the one of a container-managed persistence context may
> be set explicitly. If that has been intended it might be stated more
> clearly, if not likewise.
>

This is covered pretty explicitly in section 3.2.4:

"... a persistence context of type SynchronizationType.UNSYNCHRONIZED
or an application-managed persistence context that has been created
outside the scope of the current transaction will only be synchronized
to the database if it has been joined to the current transaction by
the application’s use of the EntityManager joinTransaction method."


>
> 3.8.1, p. 110& 3.8.2, p. 118 javadocs on
> TransactionRequiredException for getResultList and getSingleResult :
>
> Would prefer "lock mode other than NONE" like in 3.1.1.
>

OK -- I have now made the suggested additions.

>
>
> 3.3.3 Note, p. 86& 7.6.1 5th paragraph, p. 327 :
>
> The former states : "Because a transaction-scoped persistence
> context´s lifetime is scoped to a transaction regardless of whether
> it is joined to that transaction, the container closes the
> persistence context upon transaction rollback."
>
> The latter : "If a persistence context of type
> SynchronizationType.UNSYNCHRONIZED has not been joined to the current
> JTA transaction, rollback of the JTA transaction will have no effect
> upon the persistence context."
>
> Am I the only one to find this a bit confusing ?
>
>> If the group is supportive of this direction, I would like to submit a version
>> of this draft to the JCP for purposes of Early Draft Review so that we can get
>> feedback from the broader community. Please let me know if you think that
>> anything stands in the way of that.
>
> With respect to 7.4., p. 323, addNamedQuery, I would like to remind
> of the thread synchronisation issues brought up by Evan and would
> prefer to at least see them mentioned as open issue before going EDR.
>

Could you be more specific as to what you would like to see stated
in such a note? That the provider must ensure that the addNamedQuery
method is atomic? That we should contemplate adding a hasNamedQuery
method? Other?


> Thanks again for your great work, Linda !
>

And thanks again for your careful review!

best regards,

-Linda


> Best regards
> Rainer
>