A few comments.
The process described in the JTA spec on page 28 is illustrative, not prescriptive, so there is no requirement for the app server to delist the resource. That was just an example walkthrough of what *could* happen when a client closed a connection. I think you probably already knew that, though, because I think your point was just that if that *could* happen then it could break a JPA EM that wanted to write to the connection later on? Although, container data sources all pool the connections so in practice the connections never get closed, anyway (so the above case does not ever really occur).
Perhaps the strongest case is that the TransactionSynchronizationRegistry.registerInterprosedSynchronization() method in the JTA spec actually does state that beforeCompletion callback methods can access the resources, but that no transactional work can be performed on resources in afterCompletion. I would say that since the app server must provide this semantic we might be able to say that we are on reasonably firm ground. Would you agree?
On 15/06/2012 9:56 AM, Christian Romberg wrote:
Finished my research of the ejb-core (3.0), jta (1.1) and jpa (2.0) specs and found nothing, that guarantees these two behaviors.
[jpa-spec users] [jsr338-experts] Re: question regarding JPA-JTA interaction (again)