Re: No tx commit when providing ManagedRuntime

Wed, 24 Jan 2007 15:18:31 -0800 

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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
> > >>
> > >>
> >
> >
>


























					Reply via email to