You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Matthieu Riou <ma...@gmail.com> on 2007/01/15 19:35:27 UTC
No tx commit when providing ManagedRuntime
Hi,
I now have a working setup (at least something that starts) using a
programmaticaly provided datasource and transaction manager. Here is the
code now:
HashMap propMap = new HashMap();
propMap.put("openjpa.jdbc.DBDictionary", "
org.apache.openjpa.jdbc.sql.DerbyDictionary");
propMap.put("openjpa.ManagedRuntime", new TxMgrProvider());
propMap.put("openjpa.ConnectionFactory", _datasource);
propMap.put("openjpa.Log", "DefaultLevel=TRACE");
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("ode-dao",
propMap);
HashMap propMap2 = new HashMap();
propMap2.put("openjpa.TransactionMode", "managed");
EntityManager em = emf.createEntityManager(propMap2);
_daoCF = new BPELDAOConnectionFactoryImpl(em);
I've tried both with and without the propMap2, in both cases I never get
OpenJPA to commit (and therefore no insert/update/delete) when I commit the
transaction.
Any idea of what could be wrong?
Thanks!
Matthieu
Re: No tx commit when providing ManagedRuntime
Posted by Matthieu Riou <ma...@gmail.com>.
Thanks for all the options, I'll try that.
On 1/24/07, Marc Prud'hommeaux <mp...@apache.org> wrote:
>
> Matthieu-
>
> My only other guess is that you might not actually be using your
> ManagedRuntime setting, because we might need it to be a String (the
> fully-qualified class name of your ManagedRuntime implementation),
> rather than an actual instance of the class. Can you try specifying
> the class name in the "openjpa.ManagedRuntime" setting? Also, try
> enabling TRACE logging and posting the complete output from when you
> run your test, since that might help show what the value is getting
> set to.
>
> If it's not that, then I'm afraid I'm stumped.
>
> Can you try to debug it by either seeing if you can enable logging
> for the JOTM TransactionManager, or by subclassing it? I want to see
> if TransactionManager.registerSynchronization(broker) is ever being
> called. Alternately, you can put in some debugging code in
> AbstractBrokerFactory.syncWithManagedTransaction() and rebuilding
> OpenJPA and seeing if that is ever called, although that might be
> more work.
>
>
>
> On Jan 24, 2007, at 2:49 PM, Matthieu Riou wrote:
>
> > Any idea why my transaction manager setting seems to be ignored?
> >
> > Thanks,
> > Matthieu
> >
> > On 1/16/07, Matthieu Riou <ma...@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> I've tried several thing:
> >>
> >> - First I made sure that the tx was started when I get the
> >> EntityManager.
> >> - Second I've tried calling em.joinTransaction() while the
> >> transaction is
> >> being executed, didn't change anything.
> >> - Lastly I've tried to call em.flush() before commit and got the
> >> following:
> >>
> >> Caused by: <4|false|0.9.7-incubating-SNAPSHOT>
> >> org.apache.openjpa.persistence.TransactionRequiredException: Can only
> >> perform operation while a transaction is active.
> >> at
> >> org.apache.openjpa.kernel.BrokerImpl.assertActiveTransaction(
> >> BrokerImpl.java:4250)
> >> at
> >> org.apache.openjpa.kernel.DelegatingBroker.assertActiveTransaction(
> >> DelegatingBroker.java:1292)
> >> at org.apache.openjpa.persistence.EntityManagerImpl.flush(
> >> EntityManagerImpl.java:472)
> >> at org.apache.ode.bpel.engine.BpelDatabase$1.call(
> >> BpelDatabase.java:79)
> >> at
> >> org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl.execTransact
> >> ion (
> >> QuartzSchedulerImpl.java:245)
> >> at org.apache.ode.bpel.engine.BpelDatabase.exec
> >> (BpelDatabase.java
> >> :75)
> >>
> >> Seems that it doesn't see the transaction at all. Is there
> >> something I
> >> could check or make sure that the tx mgr is properly associated?
> >>
> >> Thanks,
> >>
> >> Matthieu
> >>
> >> On 1/15/07, Patrick Linskey <pl...@bea.com> wrote:
> >> >
> >> > Also, what happens if you manually call flush() at the end of your
> >> > persistence operations? This should at least tell us something
> >> about
> >> > whether or not the connections are being used correctly.
> >> >
> >> > -Patrick
> >> >
> >> > --
> >> > Patrick Linskey
> >> > BEA Systems, Inc.
> >> >
> >> >
> >> _____________________________________________________________________
> >> __
> >> > Notice: This email message, together with any attachments, may
> >> contain
> >> > information of BEA Systems, Inc., its subsidiaries and
> >> affiliated
> >> > entities, that may be confidential, proprietary, copyrighted
> >> and/or
> >> > legally privileged, and is intended solely for the use of the
> >> individual
> >> > or entity named in this message. If you are not the intended
> >> recipient,
> >> > and have received this message in error, please immediately
> >> return this
> >> > by email and then delete it.
> >> >
> >> > > -----Original Message-----
> >> > > From: Marc Prud'hommeaux [mailto: mprudhomapache@gmail.com] On
> >> > > Behalf Of Marc Prud'hommeaux
> >> > > Sent: Monday, January 15, 2007 4:22 PM
> >> > > To: open-jpa-dev@incubator.apache.org
> >> > > Subject: Re: No tx commit when providing ManagedRuntime
> >> > >
> >> > > Matthieu-
> >> > >
> >> > > That's pretty weird. What happens if you just try to manually
> >> commit
> >> > > the transaction from the EntityManager itself (with
> >> > > "em.getTransaction
> >> > > ().commit()")?
> >> > >
> >> > > Also, has the global transaction already been started as the
> >> point
> >> > > when you obtain the EntityManager from the EntityManagerFactory?
> >> > >
> >> > > Finally, what happens if you call em.joinTransaction() and then
> >> > > commit the global transaction. Any change?
> >> > >
> >> > >
> >> > >
> >> > > On Jan 15, 2007, at 3:41 PM, Matthieu Riou wrote:
> >> > >
> >> > > >> Does your TxMgrProvider provide a correctly functioning
> >> > > >> TransactionManager? OpenJPA will register a
> >> > > Synchronization with it,
> >> > > >> which should get committed when your global transaction is
> >> > > committed.
> >> > > >
> >> > > >
> >> > > > It does, I directly provide JOTM transaction manager. The
> >> > > same code
> >> > > > works
> >> > > > correctly with Hibernate as far as transaction handling is
> >> > > > concerned. My
> >> > > > managedRuntime impl is just:
> >> > > >
> >> > > > public class TxMgrProvider implements ManagedRuntime {
> >> > > > public TxMgrProvider() {
> >> > > > }
> >> > > > public TransactionManager getTransactionManager() throws
> >> > > > Exception {
> >> > > > return _txMgr;
> >> > > > }
> >> > > > }
> >> > > >
> >> > > > Do you see any log messages at all when you commit the global
> >> > > >> transaction?
> >> > > >
> >> > > >
> >> > > > No I don't. I only see some selects here and there. For example
> >> > > > there should
> >> > > > be a commit between the 2 following selects:
> >> > > >
> >> > > > 58194 ode-dao TRACE [Thread-4] openjpa.Query - Executing
> >> query:
> >> > > > select p
> >> > > > from ProcessDAOImpl p
> >> > > > 58205 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> >> > > 21912919, conn
> >> > > > 30031746> executing prepstmnt 8828117 SELECT t0.PROCESS_ID,
> >> > > > t0.VERSION,
> >> > > > t0.CONNECTION_ID , t0.GUID, t0.NUMBER_OF_INSTANCES,
> >> t0.PROCESS_KEY,
> >> > > > t0.PROCESS_TYPE FROM ODE_PROCESS t0
> >> > > > 58206 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> >> > > 21912919, conn
> >> > > > 30031746> [1 ms] spent
> >> > > > 58206 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - <t
> >> 21912919,
> >> > > > conn
> >> > > > 30031746> [0 ms] close
> >> > > > 58208 ode-dao TRACE [Thread-4] openjpa.Query - Executing
> >> query:
> >> > > > select p
> >> > > > from ProcessDAOImpl p
> >> > > > 58208 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> >> > > 21912919, conn
> >> > > > 13257390> executing prepstmnt 15527192 SELECT t0.PROCESS_ID ,
> >> > > > t0.VERSION,
> >> > > > t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES,
> >> t0.PROCESS_KEY,
> >> > > > t0.PROCESS_TYPE FROM ODE_PROCESS t0
> >> > > > 58209 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> >> > > 21912919, conn
> >> > > > 13257390> [0 ms] spent
> >> > > > 58209 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - <t
> >> 21912919,
> >> > > > conn
> >> > > > 13257390> [0 ms] close
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > > Matthieu
> >> > > >
> >> > > > On Jan 15, 2007, at 10:35 AM, Matthieu Riou wrote:
> >> > > >>
> >> > > >> > Hi,
> >> > > >> >
> >> > > >> > I now have a working setup (at least something that
> >> > > starts) using a
> >> > > >> > programmaticaly provided datasource and transaction
> >> manager. Here
> >> > > >> > is the
> >> > > >> > code now:
> >> > > >> >
> >> > > >> > HashMap propMap = new HashMap();
> >> > > >> > propMap.put("openjpa.jdbc.DBDictionary", "
> >> > > >> > org.apache.openjpa.jdbc.sql.DerbyDictionary");
> >> > > >> > propMap.put("openjpa.ManagedRuntime ", new
> >> > > TxMgrProvider());
> >> > > >> > propMap.put("openjpa.ConnectionFactory",
> >> _datasource);
> >> > > >> > propMap.put("openjpa.Log", "DefaultLevel=TRACE");
> >> > > >> > EntityManagerFactory emf =
> >> > > >> > Persistence.createEntityManagerFactory("ode-dao",
> >> > > >> > propMap);
> >> > > >> > HashMap propMap2 = new HashMap();
> >> > > >> > propMap2.put("openjpa.TransactionMode", "managed");
> >> > > >> > EntityManager em = emf.createEntityManager(propMap2);
> >> > > >> > _daoCF = new BPELDAOConnectionFactoryImpl(em);
> >> > > >> >
> >> > > >> > I've tried both with and without the propMap2, in both
> >> cases I
> >> > > >> > never get
> >> > > >> > OpenJPA to commit (and therefore no insert/update/delete)
> >> when I
> >> > > >> > commit the
> >> > > >> > transaction.
> >> > > >> >
> >> > > >> > Any idea of what could be wrong?
> >> > > >> >
> >> > > >> > Thanks!
> >> > > >> >
> >> > > >> > Matthieu
> >> > > >>
> >> > > >>
> >> > >
> >> > >
> >> >
> >>
> >>
>
>
Re: No tx commit when providing ManagedRuntime
Posted by Marc Prud'hommeaux <mp...@apache.org>.
Matthieu-
My only other guess is that you might not actually be using your
ManagedRuntime setting, because we might need it to be a String (the
fully-qualified class name of your ManagedRuntime implementation),
rather than an actual instance of the class. Can you try specifying
the class name in the "openjpa.ManagedRuntime" setting? Also, try
enabling TRACE logging and posting the complete output from when you
run your test, since that might help show what the value is getting
set to.
If it's not that, then I'm afraid I'm stumped.
Can you try to debug it by either seeing if you can enable logging
for the JOTM TransactionManager, or by subclassing it? I want to see
if TransactionManager.registerSynchronization(broker) is ever being
called. Alternately, you can put in some debugging code in
AbstractBrokerFactory.syncWithManagedTransaction() and rebuilding
OpenJPA and seeing if that is ever called, although that might be
more work.
On Jan 24, 2007, at 2:49 PM, Matthieu Riou wrote:
> Any idea why my transaction manager setting seems to be ignored?
>
> Thanks,
> Matthieu
>
> On 1/16/07, Matthieu Riou <ma...@gmail.com> wrote:
>>
>> Hi,
>>
>> I've tried several thing:
>>
>> - First I made sure that the tx was started when I get the
>> EntityManager.
>> - Second I've tried calling em.joinTransaction() while the
>> transaction is
>> being executed, didn't change anything.
>> - Lastly I've tried to call em.flush() before commit and got the
>> following:
>>
>> Caused by: <4|false|0.9.7-incubating-SNAPSHOT>
>> org.apache.openjpa.persistence.TransactionRequiredException: Can only
>> perform operation while a transaction is active.
>> at
>> org.apache.openjpa.kernel.BrokerImpl.assertActiveTransaction(
>> BrokerImpl.java:4250)
>> at
>> org.apache.openjpa.kernel.DelegatingBroker.assertActiveTransaction(
>> DelegatingBroker.java:1292)
>> at org.apache.openjpa.persistence.EntityManagerImpl.flush(
>> EntityManagerImpl.java:472)
>> at org.apache.ode.bpel.engine.BpelDatabase$1.call(
>> BpelDatabase.java:79)
>> at
>> org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl.execTransact
>> ion (
>> QuartzSchedulerImpl.java:245)
>> at org.apache.ode.bpel.engine.BpelDatabase.exec
>> (BpelDatabase.java
>> :75)
>>
>> Seems that it doesn't see the transaction at all. Is there
>> something I
>> could check or make sure that the tx mgr is properly associated?
>>
>> Thanks,
>>
>> Matthieu
>>
>> On 1/15/07, Patrick Linskey <pl...@bea.com> wrote:
>> >
>> > Also, what happens if you manually call flush() at the end of your
>> > persistence operations? This should at least tell us something
>> about
>> > whether or not the connections are being used correctly.
>> >
>> > -Patrick
>> >
>> > --
>> > Patrick Linskey
>> > BEA Systems, Inc.
>> >
>> >
>> _____________________________________________________________________
>> __
>> > Notice: This email message, together with any attachments, may
>> contain
>> > information of BEA Systems, Inc., its subsidiaries and
>> affiliated
>> > entities, that may be confidential, proprietary, copyrighted
>> and/or
>> > legally privileged, and is intended solely for the use of the
>> individual
>> > or entity named in this message. If you are not the intended
>> recipient,
>> > and have received this message in error, please immediately
>> return this
>> > by email and then delete it.
>> >
>> > > -----Original Message-----
>> > > From: Marc Prud'hommeaux [mailto: mprudhomapache@gmail.com] On
>> > > Behalf Of Marc Prud'hommeaux
>> > > Sent: Monday, January 15, 2007 4:22 PM
>> > > To: open-jpa-dev@incubator.apache.org
>> > > Subject: Re: No tx commit when providing ManagedRuntime
>> > >
>> > > Matthieu-
>> > >
>> > > That's pretty weird. What happens if you just try to manually
>> commit
>> > > the transaction from the EntityManager itself (with
>> > > "em.getTransaction
>> > > ().commit()")?
>> > >
>> > > Also, has the global transaction already been started as the
>> point
>> > > when you obtain the EntityManager from the EntityManagerFactory?
>> > >
>> > > Finally, what happens if you call em.joinTransaction() and then
>> > > commit the global transaction. Any change?
>> > >
>> > >
>> > >
>> > > On Jan 15, 2007, at 3:41 PM, Matthieu Riou wrote:
>> > >
>> > > >> Does your TxMgrProvider provide a correctly functioning
>> > > >> TransactionManager? OpenJPA will register a
>> > > Synchronization with it,
>> > > >> which should get committed when your global transaction is
>> > > committed.
>> > > >
>> > > >
>> > > > It does, I directly provide JOTM transaction manager. The
>> > > same code
>> > > > works
>> > > > correctly with Hibernate as far as transaction handling is
>> > > > concerned. My
>> > > > managedRuntime impl is just:
>> > > >
>> > > > public class TxMgrProvider implements ManagedRuntime {
>> > > > public TxMgrProvider() {
>> > > > }
>> > > > public TransactionManager getTransactionManager() throws
>> > > > Exception {
>> > > > return _txMgr;
>> > > > }
>> > > > }
>> > > >
>> > > > Do you see any log messages at all when you commit the global
>> > > >> transaction?
>> > > >
>> > > >
>> > > > No I don't. I only see some selects here and there. For example
>> > > > there should
>> > > > be a commit between the 2 following selects:
>> > > >
>> > > > 58194 ode-dao TRACE [Thread-4] openjpa.Query - Executing
>> query:
>> > > > select p
>> > > > from ProcessDAOImpl p
>> > > > 58205 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
>> > > 21912919, conn
>> > > > 30031746> executing prepstmnt 8828117 SELECT t0.PROCESS_ID,
>> > > > t0.VERSION,
>> > > > t0.CONNECTION_ID , t0.GUID, t0.NUMBER_OF_INSTANCES,
>> t0.PROCESS_KEY,
>> > > > t0.PROCESS_TYPE FROM ODE_PROCESS t0
>> > > > 58206 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
>> > > 21912919, conn
>> > > > 30031746> [1 ms] spent
>> > > > 58206 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - <t
>> 21912919,
>> > > > conn
>> > > > 30031746> [0 ms] close
>> > > > 58208 ode-dao TRACE [Thread-4] openjpa.Query - Executing
>> query:
>> > > > select p
>> > > > from ProcessDAOImpl p
>> > > > 58208 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
>> > > 21912919, conn
>> > > > 13257390> executing prepstmnt 15527192 SELECT t0.PROCESS_ID ,
>> > > > t0.VERSION,
>> > > > t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES,
>> t0.PROCESS_KEY,
>> > > > t0.PROCESS_TYPE FROM ODE_PROCESS t0
>> > > > 58209 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
>> > > 21912919, conn
>> > > > 13257390> [0 ms] spent
>> > > > 58209 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - <t
>> 21912919,
>> > > > conn
>> > > > 13257390> [0 ms] close
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Matthieu
>> > > >
>> > > > On Jan 15, 2007, at 10:35 AM, Matthieu Riou wrote:
>> > > >>
>> > > >> > Hi,
>> > > >> >
>> > > >> > I now have a working setup (at least something that
>> > > starts) using a
>> > > >> > programmaticaly provided datasource and transaction
>> manager. Here
>> > > >> > is the
>> > > >> > code now:
>> > > >> >
>> > > >> > HashMap propMap = new HashMap();
>> > > >> > propMap.put("openjpa.jdbc.DBDictionary", "
>> > > >> > org.apache.openjpa.jdbc.sql.DerbyDictionary");
>> > > >> > propMap.put("openjpa.ManagedRuntime ", new
>> > > TxMgrProvider());
>> > > >> > propMap.put("openjpa.ConnectionFactory",
>> _datasource);
>> > > >> > propMap.put("openjpa.Log", "DefaultLevel=TRACE");
>> > > >> > EntityManagerFactory emf =
>> > > >> > Persistence.createEntityManagerFactory("ode-dao",
>> > > >> > propMap);
>> > > >> > HashMap propMap2 = new HashMap();
>> > > >> > propMap2.put("openjpa.TransactionMode", "managed");
>> > > >> > EntityManager em = emf.createEntityManager(propMap2);
>> > > >> > _daoCF = new BPELDAOConnectionFactoryImpl(em);
>> > > >> >
>> > > >> > I've tried both with and without the propMap2, in both
>> cases I
>> > > >> > never get
>> > > >> > OpenJPA to commit (and therefore no insert/update/delete)
>> when I
>> > > >> > commit the
>> > > >> > transaction.
>> > > >> >
>> > > >> > Any idea of what could be wrong?
>> > > >> >
>> > > >> > Thanks!
>> > > >> >
>> > > >> > Matthieu
>> > > >>
>> > > >>
>> > >
>> > >
>> >
>>
>>
Re: No tx commit when providing ManagedRuntime
Posted by Matthieu Riou <ma...@gmail.com>.
Any idea why my transaction manager setting seems to be ignored?
Thanks,
Matthieu
On 1/16/07, Matthieu Riou <ma...@gmail.com> wrote:
>
> Hi,
>
> I've tried several thing:
>
> - First I made sure that the tx was started when I get the EntityManager.
> - Second I've tried calling em.joinTransaction() while the transaction is
> being executed, didn't change anything.
> - Lastly I've tried to call em.flush() before commit and got the
> following:
>
> Caused by: <4|false|0.9.7-incubating-SNAPSHOT>
> org.apache.openjpa.persistence.TransactionRequiredException: Can only
> perform operation while a transaction is active.
> at org.apache.openjpa.kernel.BrokerImpl.assertActiveTransaction(
> BrokerImpl.java:4250)
> at
> org.apache.openjpa.kernel.DelegatingBroker.assertActiveTransaction(
> DelegatingBroker.java:1292)
> at org.apache.openjpa.persistence.EntityManagerImpl.flush(
> EntityManagerImpl.java:472)
> at org.apache.ode.bpel.engine.BpelDatabase$1.call(
> BpelDatabase.java:79)
> at
> org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl.execTransaction (
> QuartzSchedulerImpl.java:245)
> at org.apache.ode.bpel.engine.BpelDatabase.exec(BpelDatabase.java
> :75)
>
> Seems that it doesn't see the transaction at all. Is there something I
> could check or make sure that the tx mgr is properly associated?
>
> Thanks,
>
> Matthieu
>
> On 1/15/07, Patrick Linskey <pl...@bea.com> wrote:
> >
> > Also, what happens if you manually call flush() at the end of your
> > persistence operations? This should at least tell us something about
> > whether or not the connections are being used correctly.
> >
> > -Patrick
> >
> > --
> > Patrick Linskey
> > BEA Systems, Inc.
> >
> > _______________________________________________________________________
> > Notice: This email message, together with any attachments, may contain
> > information of BEA Systems, Inc., its subsidiaries and affiliated
> > entities, that may be confidential, proprietary, copyrighted and/or
> > legally privileged, and is intended solely for the use of the individual
> > or entity named in this message. If you are not the intended recipient,
> > and have received this message in error, please immediately return this
> > by email and then delete it.
> >
> > > -----Original Message-----
> > > From: Marc Prud'hommeaux [mailto: mprudhomapache@gmail.com] On
> > > Behalf Of Marc Prud'hommeaux
> > > Sent: Monday, January 15, 2007 4:22 PM
> > > To: open-jpa-dev@incubator.apache.org
> > > Subject: Re: No tx commit when providing ManagedRuntime
> > >
> > > Matthieu-
> > >
> > > That's pretty weird. What happens if you just try to manually commit
> > > the transaction from the EntityManager itself (with
> > > "em.getTransaction
> > > ().commit()")?
> > >
> > > Also, has the global transaction already been started as the point
> > > when you obtain the EntityManager from the EntityManagerFactory?
> > >
> > > Finally, what happens if you call em.joinTransaction() and then
> > > commit the global transaction. Any change?
> > >
> > >
> > >
> > > On Jan 15, 2007, at 3:41 PM, Matthieu Riou wrote:
> > >
> > > >> Does your TxMgrProvider provide a correctly functioning
> > > >> TransactionManager? OpenJPA will register a
> > > Synchronization with it,
> > > >> which should get committed when your global transaction is
> > > committed.
> > > >
> > > >
> > > > It does, I directly provide JOTM transaction manager. The
> > > same code
> > > > works
> > > > correctly with Hibernate as far as transaction handling is
> > > > concerned. My
> > > > managedRuntime impl is just:
> > > >
> > > > public class TxMgrProvider implements ManagedRuntime {
> > > > public TxMgrProvider() {
> > > > }
> > > > public TransactionManager getTransactionManager() throws
> > > > Exception {
> > > > return _txMgr;
> > > > }
> > > > }
> > > >
> > > > Do you see any log messages at all when you commit the global
> > > >> transaction?
> > > >
> > > >
> > > > No I don't. I only see some selects here and there. For example
> > > > there should
> > > > be a commit between the 2 following selects:
> > > >
> > > > 58194 ode-dao TRACE [Thread-4] openjpa.Query - Executing query:
> > > > select p
> > > > from ProcessDAOImpl p
> > > > 58205 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> > > 21912919, conn
> > > > 30031746> executing prepstmnt 8828117 SELECT t0.PROCESS_ID,
> > > > t0.VERSION,
> > > > t0.CONNECTION_ID , t0.GUID, t0.NUMBER_OF_INSTANCES, t0.PROCESS_KEY,
> > > > t0.PROCESS_TYPE FROM ODE_PROCESS t0
> > > > 58206 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> > > 21912919, conn
> > > > 30031746> [1 ms] spent
> > > > 58206 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - <t 21912919,
> > > > conn
> > > > 30031746> [0 ms] close
> > > > 58208 ode-dao TRACE [Thread-4] openjpa.Query - Executing query:
> > > > select p
> > > > from ProcessDAOImpl p
> > > > 58208 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> > > 21912919, conn
> > > > 13257390> executing prepstmnt 15527192 SELECT t0.PROCESS_ID ,
> > > > t0.VERSION,
> > > > t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES, t0.PROCESS_KEY,
> > > > t0.PROCESS_TYPE FROM ODE_PROCESS t0
> > > > 58209 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> > > 21912919, conn
> > > > 13257390> [0 ms] spent
> > > > 58209 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - <t 21912919,
> > > > conn
> > > > 13257390> [0 ms] close
> > > >
> > > > Thanks,
> > > >
> > > > Matthieu
> > > >
> > > > On Jan 15, 2007, at 10:35 AM, Matthieu Riou wrote:
> > > >>
> > > >> > Hi,
> > > >> >
> > > >> > I now have a working setup (at least something that
> > > starts) using a
> > > >> > programmaticaly provided datasource and transaction manager. Here
> > > >> > is the
> > > >> > code now:
> > > >> >
> > > >> > HashMap propMap = new HashMap();
> > > >> > propMap.put("openjpa.jdbc.DBDictionary", "
> > > >> > org.apache.openjpa.jdbc.sql.DerbyDictionary");
> > > >> > propMap.put("openjpa.ManagedRuntime ", new
> > > TxMgrProvider());
> > > >> > propMap.put("openjpa.ConnectionFactory", _datasource);
> > > >> > propMap.put("openjpa.Log", "DefaultLevel=TRACE");
> > > >> > EntityManagerFactory emf =
> > > >> > Persistence.createEntityManagerFactory("ode-dao",
> > > >> > propMap);
> > > >> > HashMap propMap2 = new HashMap();
> > > >> > propMap2.put("openjpa.TransactionMode", "managed");
> > > >> > EntityManager em = emf.createEntityManager(propMap2);
> > > >> > _daoCF = new BPELDAOConnectionFactoryImpl(em);
> > > >> >
> > > >> > I've tried both with and without the propMap2, in both cases I
> > > >> > never get
> > > >> > OpenJPA to commit (and therefore no insert/update/delete) when I
> > > >> > commit the
> > > >> > transaction.
> > > >> >
> > > >> > Any idea of what could be wrong?
> > > >> >
> > > >> > Thanks!
> > > >> >
> > > >> > Matthieu
> > > >>
> > > >>
> > >
> > >
> >
>
>
Re: No tx commit when providing ManagedRuntime
Posted by Matthieu Riou <ma...@gmail.com>.
Hi,
I've tried several thing:
- First I made sure that the tx was started when I get the EntityManager.
- Second I've tried calling em.joinTransaction() while the transaction is
being executed, didn't change anything.
- Lastly I've tried to call em.flush() before commit and got the following:
Caused by: <4|false|0.9.7-incubating-SNAPSHOT>
org.apache.openjpa.persistence.TransactionRequiredException: Can only
perform operation while a transaction is active.
at org.apache.openjpa.kernel.BrokerImpl.assertActiveTransaction(
BrokerImpl.java:4250)
at
org.apache.openjpa.kernel.DelegatingBroker.assertActiveTransaction(
DelegatingBroker.java:1292)
at org.apache.openjpa.persistence.EntityManagerImpl.flush(
EntityManagerImpl.java:472)
at org.apache.ode.bpel.engine.BpelDatabase$1.call(BpelDatabase.java
:79)
at
org.apache.ode.bpel.scheduler.quartz.QuartzSchedulerImpl.execTransaction(
QuartzSchedulerImpl.java:245)
at org.apache.ode.bpel.engine.BpelDatabase.exec(BpelDatabase.java
:75)
Seems that it doesn't see the transaction at all. Is there something I could
check or make sure that the tx mgr is properly associated?
Thanks,
Matthieu
On 1/15/07, Patrick Linskey <pl...@bea.com> wrote:
>
> Also, what happens if you manually call flush() at the end of your
> persistence operations? This should at least tell us something about
> whether or not the connections are being used correctly.
>
> -Patrick
>
> --
> Patrick Linskey
> BEA Systems, Inc.
>
> _______________________________________________________________________
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.
>
> > -----Original Message-----
> > From: Marc Prud'hommeaux [mailto:mprudhomapache@gmail.com] On
> > Behalf Of Marc Prud'hommeaux
> > Sent: Monday, January 15, 2007 4:22 PM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: Re: No tx commit when providing ManagedRuntime
> >
> > Matthieu-
> >
> > That's pretty weird. What happens if you just try to manually commit
> > the transaction from the EntityManager itself (with
> > "em.getTransaction
> > ().commit()")?
> >
> > Also, has the global transaction already been started as the point
> > when you obtain the EntityManager from the EntityManagerFactory?
> >
> > Finally, what happens if you call em.joinTransaction() and then
> > commit the global transaction. Any change?
> >
> >
> >
> > On Jan 15, 2007, at 3:41 PM, Matthieu Riou wrote:
> >
> > >> Does your TxMgrProvider provide a correctly functioning
> > >> TransactionManager? OpenJPA will register a
> > Synchronization with it,
> > >> which should get committed when your global transaction is
> > committed.
> > >
> > >
> > > It does, I directly provide JOTM transaction manager. The
> > same code
> > > works
> > > correctly with Hibernate as far as transaction handling is
> > > concerned. My
> > > managedRuntime impl is just:
> > >
> > > public class TxMgrProvider implements ManagedRuntime {
> > > public TxMgrProvider() {
> > > }
> > > public TransactionManager getTransactionManager() throws
> > > Exception {
> > > return _txMgr;
> > > }
> > > }
> > >
> > > Do you see any log messages at all when you commit the global
> > >> transaction?
> > >
> > >
> > > No I don't. I only see some selects here and there. For example
> > > there should
> > > be a commit between the 2 following selects:
> > >
> > > 58194 ode-dao TRACE [Thread-4] openjpa.Query - Executing query:
> > > select p
> > > from ProcessDAOImpl p
> > > 58205 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> > 21912919, conn
> > > 30031746> executing prepstmnt 8828117 SELECT t0.PROCESS_ID,
> > > t0.VERSION,
> > > t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES, t0.PROCESS_KEY,
> > > t0.PROCESS_TYPE FROM ODE_PROCESS t0
> > > 58206 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> > 21912919, conn
> > > 30031746> [1 ms] spent
> > > 58206 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - <t 21912919,
> > > conn
> > > 30031746> [0 ms] close
> > > 58208 ode-dao TRACE [Thread-4] openjpa.Query - Executing query:
> > > select p
> > > from ProcessDAOImpl p
> > > 58208 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> > 21912919, conn
> > > 13257390> executing prepstmnt 15527192 SELECT t0.PROCESS_ID,
> > > t0.VERSION,
> > > t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES, t0.PROCESS_KEY,
> > > t0.PROCESS_TYPE FROM ODE_PROCESS t0
> > > 58209 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> > 21912919, conn
> > > 13257390> [0 ms] spent
> > > 58209 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - <t 21912919,
> > > conn
> > > 13257390> [0 ms] close
> > >
> > > Thanks,
> > >
> > > Matthieu
> > >
> > > On Jan 15, 2007, at 10:35 AM, Matthieu Riou wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > I now have a working setup (at least something that
> > starts) using a
> > >> > programmaticaly provided datasource and transaction manager. Here
> > >> > is the
> > >> > code now:
> > >> >
> > >> > HashMap propMap = new HashMap();
> > >> > propMap.put("openjpa.jdbc.DBDictionary", "
> > >> > org.apache.openjpa.jdbc.sql.DerbyDictionary");
> > >> > propMap.put("openjpa.ManagedRuntime", new
> > TxMgrProvider());
> > >> > propMap.put("openjpa.ConnectionFactory", _datasource);
> > >> > propMap.put("openjpa.Log", "DefaultLevel=TRACE");
> > >> > EntityManagerFactory emf =
> > >> > Persistence.createEntityManagerFactory("ode-dao",
> > >> > propMap);
> > >> > HashMap propMap2 = new HashMap();
> > >> > propMap2.put("openjpa.TransactionMode", "managed");
> > >> > EntityManager em = emf.createEntityManager(propMap2);
> > >> > _daoCF = new BPELDAOConnectionFactoryImpl(em);
> > >> >
> > >> > I've tried both with and without the propMap2, in both cases I
> > >> > never get
> > >> > OpenJPA to commit (and therefore no insert/update/delete) when I
> > >> > commit the
> > >> > transaction.
> > >> >
> > >> > Any idea of what could be wrong?
> > >> >
> > >> > Thanks!
> > >> >
> > >> > Matthieu
> > >>
> > >>
> >
> >
>
RE: No tx commit when providing ManagedRuntime
Posted by Patrick Linskey <pl...@bea.com>.
Also, what happens if you manually call flush() at the end of your
persistence operations? This should at least tell us something about
whether or not the connections are being used correctly.
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
> -----Original Message-----
> From: Marc Prud'hommeaux [mailto:mprudhomapache@gmail.com] On
> Behalf Of Marc Prud'hommeaux
> Sent: Monday, January 15, 2007 4:22 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: No tx commit when providing ManagedRuntime
>
> Matthieu-
>
> That's pretty weird. What happens if you just try to manually commit
> the transaction from the EntityManager itself (with
> "em.getTransaction
> ().commit()")?
>
> Also, has the global transaction already been started as the point
> when you obtain the EntityManager from the EntityManagerFactory?
>
> Finally, what happens if you call em.joinTransaction() and then
> commit the global transaction. Any change?
>
>
>
> On Jan 15, 2007, at 3:41 PM, Matthieu Riou wrote:
>
> >> Does your TxMgrProvider provide a correctly functioning
> >> TransactionManager? OpenJPA will register a
> Synchronization with it,
> >> which should get committed when your global transaction is
> committed.
> >
> >
> > It does, I directly provide JOTM transaction manager. The
> same code
> > works
> > correctly with Hibernate as far as transaction handling is
> > concerned. My
> > managedRuntime impl is just:
> >
> > public class TxMgrProvider implements ManagedRuntime {
> > public TxMgrProvider() {
> > }
> > public TransactionManager getTransactionManager() throws
> > Exception {
> > return _txMgr;
> > }
> > }
> >
> > Do you see any log messages at all when you commit the global
> >> transaction?
> >
> >
> > No I don't. I only see some selects here and there. For example
> > there should
> > be a commit between the 2 following selects:
> >
> > 58194 ode-dao TRACE [Thread-4] openjpa.Query - Executing query:
> > select p
> > from ProcessDAOImpl p
> > 58205 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> 21912919, conn
> > 30031746> executing prepstmnt 8828117 SELECT t0.PROCESS_ID,
> > t0.VERSION,
> > t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES, t0.PROCESS_KEY,
> > t0.PROCESS_TYPE FROM ODE_PROCESS t0
> > 58206 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> 21912919, conn
> > 30031746> [1 ms] spent
> > 58206 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - <t 21912919,
> > conn
> > 30031746> [0 ms] close
> > 58208 ode-dao TRACE [Thread-4] openjpa.Query - Executing query:
> > select p
> > from ProcessDAOImpl p
> > 58208 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> 21912919, conn
> > 13257390> executing prepstmnt 15527192 SELECT t0.PROCESS_ID,
> > t0.VERSION,
> > t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES, t0.PROCESS_KEY,
> > t0.PROCESS_TYPE FROM ODE_PROCESS t0
> > 58209 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t
> 21912919, conn
> > 13257390> [0 ms] spent
> > 58209 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - <t 21912919,
> > conn
> > 13257390> [0 ms] close
> >
> > Thanks,
> >
> > Matthieu
> >
> > On Jan 15, 2007, at 10:35 AM, Matthieu Riou wrote:
> >>
> >> > Hi,
> >> >
> >> > I now have a working setup (at least something that
> starts) using a
> >> > programmaticaly provided datasource and transaction manager. Here
> >> > is the
> >> > code now:
> >> >
> >> > HashMap propMap = new HashMap();
> >> > propMap.put("openjpa.jdbc.DBDictionary", "
> >> > org.apache.openjpa.jdbc.sql.DerbyDictionary");
> >> > propMap.put("openjpa.ManagedRuntime", new
> TxMgrProvider());
> >> > propMap.put("openjpa.ConnectionFactory", _datasource);
> >> > propMap.put("openjpa.Log", "DefaultLevel=TRACE");
> >> > EntityManagerFactory emf =
> >> > Persistence.createEntityManagerFactory("ode-dao",
> >> > propMap);
> >> > HashMap propMap2 = new HashMap();
> >> > propMap2.put("openjpa.TransactionMode", "managed");
> >> > EntityManager em = emf.createEntityManager(propMap2);
> >> > _daoCF = new BPELDAOConnectionFactoryImpl(em);
> >> >
> >> > I've tried both with and without the propMap2, in both cases I
> >> > never get
> >> > OpenJPA to commit (and therefore no insert/update/delete) when I
> >> > commit the
> >> > transaction.
> >> >
> >> > Any idea of what could be wrong?
> >> >
> >> > Thanks!
> >> >
> >> > Matthieu
> >>
> >>
>
>
Re: No tx commit when providing ManagedRuntime
Posted by Marc Prud'hommeaux <mp...@apache.org>.
Matthieu-
That's pretty weird. What happens if you just try to manually commit
the transaction from the EntityManager itself (with "em.getTransaction
().commit()")?
Also, has the global transaction already been started as the point
when you obtain the EntityManager from the EntityManagerFactory?
Finally, what happens if you call em.joinTransaction() and then
commit the global transaction. Any change?
On Jan 15, 2007, at 3:41 PM, Matthieu Riou wrote:
>> Does your TxMgrProvider provide a correctly functioning
>> TransactionManager? OpenJPA will register a Synchronization with it,
>> which should get committed when your global transaction is committed.
>
>
> It does, I directly provide JOTM transaction manager. The same code
> works
> correctly with Hibernate as far as transaction handling is
> concerned. My
> managedRuntime impl is just:
>
> public class TxMgrProvider implements ManagedRuntime {
> public TxMgrProvider() {
> }
> public TransactionManager getTransactionManager() throws
> Exception {
> return _txMgr;
> }
> }
>
> Do you see any log messages at all when you commit the global
>> transaction?
>
>
> No I don't. I only see some selects here and there. For example
> there should
> be a commit between the 2 following selects:
>
> 58194 ode-dao TRACE [Thread-4] openjpa.Query - Executing query:
> select p
> from ProcessDAOImpl p
> 58205 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t 21912919, conn
> 30031746> executing prepstmnt 8828117 SELECT t0.PROCESS_ID,
> t0.VERSION,
> t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES, t0.PROCESS_KEY,
> t0.PROCESS_TYPE FROM ODE_PROCESS t0
> 58206 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t 21912919, conn
> 30031746> [1 ms] spent
> 58206 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - <t 21912919,
> conn
> 30031746> [0 ms] close
> 58208 ode-dao TRACE [Thread-4] openjpa.Query - Executing query:
> select p
> from ProcessDAOImpl p
> 58208 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t 21912919, conn
> 13257390> executing prepstmnt 15527192 SELECT t0.PROCESS_ID,
> t0.VERSION,
> t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES, t0.PROCESS_KEY,
> t0.PROCESS_TYPE FROM ODE_PROCESS t0
> 58209 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t 21912919, conn
> 13257390> [0 ms] spent
> 58209 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - <t 21912919,
> conn
> 13257390> [0 ms] close
>
> Thanks,
>
> Matthieu
>
> On Jan 15, 2007, at 10:35 AM, Matthieu Riou wrote:
>>
>> > Hi,
>> >
>> > I now have a working setup (at least something that starts) using a
>> > programmaticaly provided datasource and transaction manager. Here
>> > is the
>> > code now:
>> >
>> > HashMap propMap = new HashMap();
>> > propMap.put("openjpa.jdbc.DBDictionary", "
>> > org.apache.openjpa.jdbc.sql.DerbyDictionary");
>> > propMap.put("openjpa.ManagedRuntime", new TxMgrProvider());
>> > propMap.put("openjpa.ConnectionFactory", _datasource);
>> > propMap.put("openjpa.Log", "DefaultLevel=TRACE");
>> > EntityManagerFactory emf =
>> > Persistence.createEntityManagerFactory("ode-dao",
>> > propMap);
>> > HashMap propMap2 = new HashMap();
>> > propMap2.put("openjpa.TransactionMode", "managed");
>> > EntityManager em = emf.createEntityManager(propMap2);
>> > _daoCF = new BPELDAOConnectionFactoryImpl(em);
>> >
>> > I've tried both with and without the propMap2, in both cases I
>> > never get
>> > OpenJPA to commit (and therefore no insert/update/delete) when I
>> > commit the
>> > transaction.
>> >
>> > Any idea of what could be wrong?
>> >
>> > Thanks!
>> >
>> > Matthieu
>>
>>
Re: No tx commit when providing ManagedRuntime
Posted by Matthieu Riou <ma...@gmail.com>.
> Does your TxMgrProvider provide a correctly functioning
> TransactionManager? OpenJPA will register a Synchronization with it,
> which should get committed when your global transaction is committed.
It does, I directly provide JOTM transaction manager. The same code works
correctly with Hibernate as far as transaction handling is concerned. My
managedRuntime impl is just:
public class TxMgrProvider implements ManagedRuntime {
public TxMgrProvider() {
}
public TransactionManager getTransactionManager() throws Exception {
return _txMgr;
}
}
Do you see any log messages at all when you commit the global
> transaction?
No I don't. I only see some selects here and there. For example there should
be a commit between the 2 following selects:
58194 ode-dao TRACE [Thread-4] openjpa.Query - Executing query: select p
from ProcessDAOImpl p
58205 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t 21912919, conn
30031746> executing prepstmnt 8828117 SELECT t0.PROCESS_ID, t0.VERSION,
t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES, t0.PROCESS_KEY,
t0.PROCESS_TYPE FROM ODE_PROCESS t0
58206 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t 21912919, conn
30031746> [1 ms] spent
58206 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - <t 21912919, conn
30031746> [0 ms] close
58208 ode-dao TRACE [Thread-4] openjpa.Query - Executing query: select p
from ProcessDAOImpl p
58208 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t 21912919, conn
13257390> executing prepstmnt 15527192 SELECT t0.PROCESS_ID, t0.VERSION,
t0.CONNECTION_ID, t0.GUID, t0.NUMBER_OF_INSTANCES, t0.PROCESS_KEY,
t0.PROCESS_TYPE FROM ODE_PROCESS t0
58209 ode-dao TRACE [Thread-4] openjpa.jdbc.SQL - <t 21912919, conn
13257390> [0 ms] spent
58209 ode-dao TRACE [Thread-4] openjpa.jdbc.JDBC - <t 21912919, conn
13257390> [0 ms] close
Thanks,
Matthieu
On Jan 15, 2007, at 10:35 AM, Matthieu Riou wrote:
>
> > Hi,
> >
> > I now have a working setup (at least something that starts) using a
> > programmaticaly provided datasource and transaction manager. Here
> > is the
> > code now:
> >
> > HashMap propMap = new HashMap();
> > propMap.put("openjpa.jdbc.DBDictionary", "
> > org.apache.openjpa.jdbc.sql.DerbyDictionary");
> > propMap.put("openjpa.ManagedRuntime", new TxMgrProvider());
> > propMap.put("openjpa.ConnectionFactory", _datasource);
> > propMap.put("openjpa.Log", "DefaultLevel=TRACE");
> > EntityManagerFactory emf =
> > Persistence.createEntityManagerFactory("ode-dao",
> > propMap);
> > HashMap propMap2 = new HashMap();
> > propMap2.put("openjpa.TransactionMode", "managed");
> > EntityManager em = emf.createEntityManager(propMap2);
> > _daoCF = new BPELDAOConnectionFactoryImpl(em);
> >
> > I've tried both with and without the propMap2, in both cases I
> > never get
> > OpenJPA to commit (and therefore no insert/update/delete) when I
> > commit the
> > transaction.
> >
> > Any idea of what could be wrong?
> >
> > Thanks!
> >
> > Matthieu
>
>
Re: No tx commit when providing ManagedRuntime
Posted by Marc Prud'hommeaux <mp...@apache.org>.
Matthieu-
Does your TxMgrProvider provide a correctly functioning
TransactionManager? OpenJPA will register a Synchronization with it,
which should get committed when your global transaction is committed.
Do you see any log messages at all when you commit the global
transaction?
On Jan 15, 2007, at 10:35 AM, Matthieu Riou wrote:
> Hi,
>
> I now have a working setup (at least something that starts) using a
> programmaticaly provided datasource and transaction manager. Here
> is the
> code now:
>
> HashMap propMap = new HashMap();
> propMap.put("openjpa.jdbc.DBDictionary", "
> org.apache.openjpa.jdbc.sql.DerbyDictionary");
> propMap.put("openjpa.ManagedRuntime", new TxMgrProvider());
> propMap.put("openjpa.ConnectionFactory", _datasource);
> propMap.put("openjpa.Log", "DefaultLevel=TRACE");
> EntityManagerFactory emf =
> Persistence.createEntityManagerFactory("ode-dao",
> propMap);
> HashMap propMap2 = new HashMap();
> propMap2.put("openjpa.TransactionMode", "managed");
> EntityManager em = emf.createEntityManager(propMap2);
> _daoCF = new BPELDAOConnectionFactoryImpl(em);
>
> I've tried both with and without the propMap2, in both cases I
> never get
> OpenJPA to commit (and therefore no insert/update/delete) when I
> commit the
> transaction.
>
> Any idea of what could be wrong?
>
> Thanks!
>
> Matthieu