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

From: Emmanuel Bernard <>
Date: Tue, 29 Nov 2011 20:08:47 +0100

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.


> 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.

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?

In particular section 7.6.1 seems generic to me and not specific to container managed persistence contexts

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.

> 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.
> 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?
- what happens if no Tx is present?

> 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.
We don't have EPC outside Stateful Session Beans so the open question does not apply. Am I 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.
> 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.

> 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.


On 9 nov. 2011, at 02:01, Linda DeMichiel wrote:

> I've uploaded a new specification draft to the project Documents area
> (
> 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.