Adding the explicit line in the persistence.xml for the SunAS9 target
appears to have fixed it. Oddly, it appears no longer necessary to
explicitly invoke the joinTransaction method to get the entity manager to
participate. I've got a lot of test code to cleanup and reverify but I'm
thinking the issue has been addressed.
Thanks again!
- Phillip
On Thu, Mar 3, 2011 at 11:48 PM, Phillip Ross <phillip.w.g.ross_at_gmail.com>wrote:
> Actually I was mistaken on a previous email. Surrounding with local JPA
> transaction control operations DOES seem to function and cause the data to
> be persisted to the database. I'm surprised this does not throw an illegal
> state exception which I seem to recall happening when trying to work with
> JPA local transactions on a persistence unit set to JTA.
>
> Mitesh, I'm going to set the server platform property to SunAS9 and see if
> that helps. I definitely did not have to do that with glassfish 3.0.1
> though.
>
> Regarding interception, do you mean to say that glassfish does nothing to
> intercept the process of acquiring an EMF or EM when using
> javax.persistence.Persistence? If that's the case then this would imply
> that this is an eclipselink issue and not glassfish?
>
> I'll try the SunAS9 platform setting and see if that helps, but I'm
> thinking I'll have to ping the eclipselink guys on this issue next. They've
> always been consistently super helpful on toplink/eclipselink issues I've
> had in the past. I've also located the eclipselink source code for
> javax.persistence.Persistence so will probably dig in there and do some
> comparisons with 2.1 and 2.2.
>
> Thanks for the help thus far, I'll report on my findings.
>
> - Phillip
>
>
> On Thu, Mar 3, 2011 at 8:51 PM, Marina Vatkina <marina.vatkina_at_oracle.com>wrote:
>
>> Phillip said that even looking it up doesn't help...
>>
>> -marina
>>
>>
>> Mitesh Meswani wrote:
>>
>>> It is user code that is instantiating EMF using Persistence.createEMF().
>>> We do not get chance to intercept
>>> On 3/3/2011 4:59 PM, Marina Vatkina wrote:
>>>
>>>> Mitesh,
>>>>
>>>> don't we set this when processing the PU?
>>>>
>>>> thanks,
>>>> -marina
>>>>
>>>> Mitesh Meswani wrote:
>>>>
>>>>> For EclipseLink to be aware of GlassFish TransactionManager, you need
>>>>> to specify <property name="eclipselink.target-server" value="SunAS9"/> .
>>>>> Without this property I do not think your use case would have worked in
>>>>> 3.0.1 either.
>>>>>
>>>>> Thanks,
>>>>> Mitesh
>>>>> On 3/3/2011 11:36 AM, Phillip Ross wrote:
>>>>>
>>>>>> Here's an inline, slightly abbreviated version of my persistence.xml
>>>>>>
>>>>>> <?xml version="1.0" encoding="UTF-8"?>
>>>>>> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>> xsi:schemaLocation="
>>>>>> http://java.sun.com/xml/ns/persistence
>>>>>> http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
>>>>>> version="2.0">
>>>>>>
>>>>>> <persistence-unit name="default" transaction-type="JTA">
>>>>>> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
>>>>>> <jta-data-source>jdbc/test_ds</jta-data-source>
>>>>>> <class>TestEntity</class>
>>>>>> <properties>
>>>>>> <property name="eclipselink.logging.level" value="SEVERE"/>
>>>>>> </properties>
>>>>>> </persistence-unit>
>>>>>> </persistence>
>>>>>>
>>>>>> The real one has a different datasource name and lots more, real class
>>>>>> names, but this one illustrates the pu name and tx type I'm attempting to
>>>>>> use.
>>>>>>
>>>>>> Another interesting datapoint, I added some code to interrogate the
>>>>>> entity manager and it seems to not know the server platform or claim to
>>>>>> support JTA. Code looks like this:
>>>>>> Object entityManagerDelegateObject = entityManager.getDelegate();
>>>>>> logger.debug("Retrieved a delegate object of type {}",
>>>>>> entityManagerDelegateObject.getClass().getName());
>>>>>> if (entityManagerDelegateObject instanceof EntityManagerImpl) {
>>>>>> EntityManagerImpl entityManagerImpl =
>>>>>> (EntityManagerImpl)entityManager.getDelegate();
>>>>>> Session session = entityManagerImpl.getSession();
>>>>>> ServerPlatform serverPlatform =
>>>>>> session.getServerPlatform();
>>>>>> logger.debug("server platform: {}",
>>>>>> serverPlatform.getServerNameAndVersion());
>>>>>> logger.debug("jta enabled: {}",
>>>>>> serverPlatform.isJTAEnabled());
>>>>>> }
>>>>>>
>>>>>> And the output from this looks like this:
>>>>>> - Retrieved a delegate object of type
>>>>>> org.eclipse.persistence.internal.jpa.EntityManagerImpl
>>>>>> - server platform: null
>>>>>> - jta enabled: false
>>>>>>
>>>>>> But placing the same code inside a stateless EJB produces this output:
>>>>>> - server platform: unknown
>>>>>> - jta enabled: true
>>>>>>
>>>>>> I dont really know if this has anything to do with anything, but
>>>>>> thought it was interesting.
>>>>>>
>>>>>>
>>>>>> On Thu, Mar 3, 2011 at 1:33 PM, Mitesh Meswani <
>>>>>> mitesh.meswani_at_oracle.com <mailto:mitesh.meswani_at_oracle.com>> wrote:
>>>>>>
>>>>>> On 3/3/2011 10:30 AM, Phillip Ross wrote:
>>>>>>
>>>>>> at
>>>>>>
>>>>>> org.eclipse.persistence.internal.jpa.transaction.EntityTransactionWrapper.checkForTransaction(EntityTransactionWrapper.java:50)
>>>>>>
>>>>>>
>>>>>> Use of EntityTransactionWrapper implies that you are not using a
>>>>>> JTA pu. Check your persistence.xml to make sure that it is a JTA
>>>>>> pu.
>>>>>>
>>>>>> -Mitesh
>>>>>>
>>>>>> at
>>>>>>
>>>>>> org.eclipse.persistence.internal.jpa.EntityManagerImpl.checkForTransaction(EntityManagerImpl.java:1666)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>