On 11/29/2011 11:08 AM, Emmanuel Bernard wrote:
> Hi Linda and all,
> Here are some comments on the changes for chapter 3, 7 and section 10.4.1. I apologize for taking so long. I'd also like to say that it ends up being much more readable and understandable than what I had anticipated so kudos to Linda.
>
>
> 3.2.4
>
>> OPEN ISSUE: The wording above now implies that an application-managed persistence context that has not been joined
>> to the current transaction must not be flushed to the database. I believe this was either unspecified (or permitted) previously.
>> Is this the semantics we want?
>
> Yes it looks appropriate and more consistent to me.
>
OK, thanks. Unless anyone sees any problems with this, I plan to remove the "open issue" note.
> 3.3.1
> I'd like your opinion on how we treat application managed persistence contexts. According to 3.3.1, we treat them as SYNCHRONIZED all the time. There is no way to make an application-managed persistence context simulate what a container-managed persistence context. This lack of symmetry makes me uneasy in and of itself but also in the perspective of extending this to the SE world.
> Any reason why we disallow UNSYNCHRONIZED application-managed persistence contexts?
>
Not really. Actually, I'd like to hear from the group as to whether we should extend the spec
in that direction.
> In particular section 7.6.1 seems generic to me and not specific to container managed persistence contexts
>
> 7.4
> EntityManagerFactory.addNamedQuery
> As I raised initially, I'm still unclear how a user would properly use this feature. Where in his code would it add a new named query and make sure this has not been added before. To me it'd be preferable to have some initialization hook to set such queries. I'm happy to change my mind but I looked up my emails and I don't think anyone came up with a use case for the current proposed form.
> Note that this also avoid a bunch of concurrent safe structures as well but that's impl details.
>
> See the thread named Re: named queries and my exchange with Gordon from April 28th forward.
>
OK. Unfortunately, we don't have a well-defined initialization sequence, and the EMF
may be created by the container before application code gets to execute. However, a
startup singleton EJB's postConstruct could be used for adding named queries, or a
servlet init method. In the mean time, do you think addNamedQuery has so little
value that we should remove it?
> 7.6.3
>> OPEN ISSUE: Support for allowing components other than stateful session beans to initiate container-managed extended persistence contexts.
>
> What do you have in mind precisely?
> I was thinking that CDI would want this kind of feature but I remembered that an application managed PC is by design an extended PC and that other programmatic models (than EJB) can piggyback on this. Still we could think of a nicer user experience if we manage to standardize this somehow or at least think of it as cross JSR EGs.
>
This is a placeholder that was triggered by a more general CDI-related discussion I
was having with Pete. Creation of a JIRA is a to-do item that has been on my list
for some time, and I should really move this issue there as it is more of an RFE.
> 7.6.3.1
>> If the stateful session beans differ in declared synchronization type, the EJBException is thrown by the container.
>
> Wild thought, should we try and make sure an deployment time exception occurs? That would be much better and nicer than waiting for the first call to blow up on the user.
>
>
> I don't think the spec defines what's going on if a SfulSB defines an EPC and called upon a SlessSB which defines a PC. It might be implied but that was not clear from my readings:
> - if a JTA tx is present, is the PC propagated? Or is a new PC created for the SlessSB?
PC is propagated to the SLSB
> - what happens if no Tx is present?
No propagation
>
> 7.6.4
>> OPEN ISSUE: Whether to add support for the propagation of extended persistence contexts when no transaction exists.
>
> Does this use case applies currently ? Let me know if I derail.
>
> EPC are propagated along Stateful Session Beans regardless of a transaction so this side is covered.
Sort of. The terminology the spec uses is "inheritance", since it is pegged to creation rather
than to transactional propagation. After the EPC is created in this way, it propagates normally.
> We don't have EPC outside Stateful Session Beans so the open question does not apply. Am I correct?
>
Correct
> Say we open up EPC for non SfulSB, then, I think it would be nice to get EPC propagation even without transaction to mimic what SfulSB do.
>
Other than in the abstract, do you see a compelling use case for this?
> 7.6.4.1
>> OPEN ISSUE: Should this be permitted if the former persistence context has been joined to the JTA transaction?
>
> I can see why users would expect that to work. Unfortunately that's not something we can catch as a deployment time error and thus, I'd rather allow that to limit bugs in production.
> What would be the downside of allowing such thing (gotchas or limit for future evolutions)? I can't see any right now.
>
I think it could work, but not sure what the right thing to do here is.
> 7.9.2
>> OPEN ISSUE: This contract will presumably need to change, as the provider needs to know which type of persistence
>> context is being created (SYNCHRONIZED or UNSYNCHRO- NIZED) so that it knows whether to register for synchronization
>> notifications or not. We will presumably need to define a standard property that the container passes in as part of the map passed
>> to the createEntityManager invocation.
>
> +1 for using the Map and not using an overloaded method. Note that this weight in favor of allowing app-managed PC to be UNSYNCHRONIZED if they wish to.
>
Agree.
thanks for the feedback
-Linda
> Emmanuel
>
> On 9 nov. 2011, at 02:01, Linda DeMichiel wrote:
>
>>
>> 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.
>>
>> Please review these changes carefully, and post any comments or corrections.
>>
>> 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.
>>
>> thanks,
>>
>> -Linda
>>
>> p.s. The changebars are additive from the last draft, so that all changes
>> since JPA 2.0 will be flagged when we submit a JCP draft.
>