On 3/3/2011 9:46 PM, Phillip Ross wrote:
> 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.
That is a "value add" from EclipseLink. You should always have the
joinTransaction() call to ensure portability.
-Mitesh
> 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 <mailto: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 <mailto: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>
> <mailto: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)
>
>
>
>
>
>
>
>