You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Jack Cai <gr...@gmail.com> on 2010/01/11 04:42:22 UTC
Re: Cannot using Geronimo to execute bean-managed transaction with
oracle transaction more than once, but Glassfish does
I see that ManagedXAConnection will set autoCommit to false in
localTransactionStart(). So you mean Geronimo is enlisting the resouce
before it starts the local transaction?
I see ManagedXAConnection also sets autoCommit to true in
localTransactionCommit() and localTransactionRollback(), so it's not
only the cleanup() method.
-Jack
On Thu, Jan 7, 2010 at 8:42 PM, ext2 <xu...@tongtech.com> wrote:
> Hi David Jeck:
>
> If the tranql's oracle wrapper is changed, the oracle will works well. And
> user doesn't need write to a un-usual program at application level;
>
> Although I am still not agree to the Geronimo 's current action, but anyway
> it's just another design strategy: now the database vendor has some trivial
> difference , so the middle-ware (application-server) should has the
> responsible to shield the difference and always give a consistence
> appearance to the end-user; That's the strategy I finally decide to use in
> my work (it's not a app-server, but still provide jta features);
>
> Best regard
> Ext2
> -----Origin-----
> Sender: David Jencks [mailto:david_jencks@yahoo.com]
> Date: 2010-1-7 17:23
> Receiver: user@geronimo.apache.org
> Subject: Re: Cannot using Geronimo to execute bean-managed transaction with
> oracle transaction more than once, but Glassfish does
>
>
> On Jan 6, 2010, at 11:21 PM, ext2 wrote:
>
>> Hi, David Jeck:
>>
>> Sorry , I forget to said
>>> or, does the connection have to have auto commit set to true or set
>>> to
>>> false (which one)?
>> At the point of JTA's view, set auto commit has no other means, so
>> we need
>> not affect it and read it while using JTA; this works for most
>> database in
>> Geronimo, But oracle whose usage is different, only because of a
>> bug of
>> tranql. At application level ,we can only to resole the bug in a un-
>> usual
>> way.
>
> As I said, I haven't read the spec in several years, but I think this
> is a bug in oracle. My recollection is that the autocommit state is
> supposed to be ignored when enlisting in a JTA transaction. There
> are other oracle bugs related to autocommit, for instance the spec
> clearly says that (using local transactions) if autocommit is false,
> setting it to true should commit pending work, but oracle does not.
>
>>
>> Although setting auto commit has no other means in JTA, but this
>> doesn't
>> means the application-server has no responsible to check it.
>
> My recollection of the spec is that the app server has no need to
> check the autocommit state since enlisting in a jta transaction should
> cause the autocommit state to be ignored no matter what it is.
>
>> And that is
>> what I doest agree to Geronimo 's current action;
>
> We can probably fix this in the tranql oracle wrapper. Geronimo
> doesn't even know that it's dealing with a jdbc driver, so it has no
> knowledge of the autocommit property's existence.
>
> thanks
> david jencks
>
>>
>> -----Origin-----
>> Sender: David Jencks [mailto:david_jencks@yahoo.com]
>> Date: 2010-1-7 2:03
>> Receiver: user@geronimo.apache.org
>> Subject: Re: Cannot using Geronimo to execute bean-managed
>> transaction with
>> oracle transaction more than once, but Glassfish does
>>
>>
>> On Jan 6, 2010, at 3:05 AM, ext2 wrote:
>>
>>> The problem is caused by tranql-commons-connector is not compatible
>>> with
>>> Oracle 9i 's XA API. The details things happened as following
>>> description.
>>>
>>> When the XA transaction finished, the ManagedXAConnection(tranql)
>>> will be
>>> cleanup and put back to the pool. While cleanup the
>>> ManagedXAConnection,
>>> tranql reset the associated physical connection 's auto commit to
>>> true.
>>> Because at this time, Transaction Manager has finished the XA
>>> transaction,
>>> so reset the commit to true will acceptable by Oralce's XA driver;
>>>
>>> So unfortunately this will cause the XA resource cannot be enlist
>>> into
>>> transaction next time. and you can only execute the xa-transaction
>>> only
>>> once;
>>
>> It's been a long time since I looked into this, but if I remember the
>> spec correctly oracle's driver is not spec compliant here. I'm not
>> sure I understand exactly what sequences of operations are allowed by
>> oracle and which are not.
>>
>> if you call setAutocommit on a connection, either true or false, does
>> that prevent the associated managed connection from ever being
>> enlisted in an XA transaction?
>>
>> or, does the connection have to have autocommit set to true or set to
>> false (which one)?
>>
>> I don't have an easy way to set up oracle here to investigate this for
>> myself, I hope I'm asking my questions clearly enough to be
>> understood.
>>
>> thanks
>> david jencks
>>
>>
>>>
>>> -----Original -----
>>> Sender: xuhongbo [mailto:xuhb@tongtech.com]
>>> Date: 2009-12-30 17:15
>>> Receiver: user@geronimo.apache.org
>>> Subject: Re: Reply: Cannot using Geronimo to execute bean-managed
>>> transaction with oracle transaction more than once, but Glassfish
>>> does
>>>
>>> Hi Jack Cai:
>>>
>>> I have tried, the "tranql-connector-oracle-local" is ok, but it
>>> doesn't use
>>> xa transaction in jta, and use a faked Local-XAResource instead of
>>> real
>>> oracle-xa-resource;
>>>
>>> I am sorry to mis-understand your means and give the run-time class
>>> name in
>>> my previous reply; The error occurred program is just using "
>>> tranql-connector-oracle-xa"
>>>
>>> Additionally, I have try another Mysql database and using "
>>> tranql-connector-mysql-xa" do real xa transaction. It works well.
>>>
>>> So my mind changed, maybe there is something not compatible with
>>> oracle 9i
>>> database; In my original mail, I have post a very simple program
>>> which use
>>> the Geronimo Transaction Manager and Oracle XA API directly, this
>>> works
>>> well;
>>>
>>> Because tranql resource adaptor is a very simple wrapper , Geronimo
>>> does
>>> additional things to wrap the database connection (etc control
>>> pooling,
>>> xa-resource wrap, xa-resource cache for transaction-manager ...) ,
>>> so I am
>>> wondering if there is some other un-excepted database operation has
>>> been
>>> done and cause this problem? for convenience I post the simple
>>> program
>>> again.
>>>
>>> If we only concern database operation, does this simple program done
>>> exactly like the Geronimo done ? Or it doesn't , Geronimo do
>>> additional
>>> things... maybe the difference will be the real reason cause the
>>> problem;
>>> I have tracked at runtime, but unfortunately has not find some
>>> difference
>>> yet...
>>>
>>> Thanks a lot
>>> xuhongbo
>>>
>>>
>>> -----origin-----
>>> sender: Jack Cai [mailto:greensight@gmail.com]
>>> date: 2009/12/30 11:45
>>> receiver: user@geronimo.apache.org
>>> subject: Re: Reply: Cannot using Geronimo to execute bean-managed
>>> transaction with oracle transaction more than once, but Glassfish
>>> does
>>>
>>> Can you try to use the tranql-connector-oracle-xa or
>>> tranql-connector-oracle-local to do the test?
>>>
>>> -Jack
>>>
>>> On Wed, Dec 30, 2009 at 11:26 AM, xuhongbo <xu...@tongtech.com> wrote:
>>>>
>>>>>> In the future it would be great if you could only post to one
>>>>>> mailing
>>>>>> list.
>>>> Thanks, I know
>>>>
>>>>>> I'm not sure what is wrong yet, however you should never try to
>>>>>> set
>>>>>> the autocommit state of a connection that is enlisted in a jta
>>>>>> transaction. Enlisting and delisting the XAConnection will
>>>>>> result in
>>>>>> the autocommit being dealt with properly. The value from
>>>>>> getAutoCommit may or may not be meaningful in a jta transaction.
>>>>>> Outside a jta transaction the autocommit state defaults to true.
>>>>>> I'm
>>>>>> quite surprised you didn't get a more informative error.
>>>>
>>>> Yes you are right, auto commit has no means for jta connection and
>>>> cannot
>>> be
>>>> set to true; here I just set auto commit to false, so a jta
>>>> connection
>>>> should just omit it;
>>>> But the surprise thing is if I doesn't affect auto commit state(in
>>>> the
>>>> program, just comment the statement "setAutocommit(false)"), when
>>>> execute
>>>> database operation, a "ORA-02089: COMMIT ..." exception will be
>>>> throwed
>>> by
>>>> oracle's database driver; it looks like the Geronimo does a wrong
>>>> things
>>>> "commit on the connection when execute database operation"; and this
>>> should
>>>> only occurs on non-jta connection, because only no-jta connection
>>>> will set
>>>> auto commit default to true.
>>>>
>>>>>> One important piece of information that I don't see is which
>>>>>> tranql
>>>>>> wrapper you used to deploy your datasource.
>>>>
>>>> The datasource is org.tranql.connector.jdbc.DataSource. And it
>>>> use a a
>>>> managed-connection factory " org.tranql.connector.oracle.XAMCF" to
>>>> open
>>>> connection; And the managed-connection factory use a oracle's xa
>>> datasource
>>>> (oracle.jdbc.xa.client.OracleXADataSource);
>>>>
>>>> By the way , I haven't ever post a trivial problem I have meet
>>>> when I
>>> deploy
>>>> the Oracle-XA data source. The trivial thing is: I must change the
>>>> deploy
>>>> plan created by Geronimo's web manage console tools, delete the
>>>> empty
>>>> property "TNSEntryName" and manually deploy it; because this is the
>>> oracle9i
>>>> database driver's question --- "a empty string value(not a null
>>>> value) set
>>>> to TNSEntryName" will cause oracle9i's database driver to omit the
>>>> other
>>>> property (etc serverName, serviceName ...) and cannot establish a
>>>> connect
>>> ;
>>>> I thinks this should have no means to the transaction commit
>>>> failure; but
>>>> maybe it would give some other useful things help to find out the
>>>> reason.
>>>>
>>>> Thanks a lot
>>>> xuhongbo
>>>>
>>>> -----origin -----
>>>> sender: David Jencks [mailto:david_jencks@yahoo.com]
>>>> date: 2009/12/30 1:43
>>>> receiver: user@geronimo.apache.org
>>>> subject: Re: Reply: Cannot using Geronimo to execute bean-managed
>>>> transaction with oracle transaction more than once, but Glassfish
>>>> does
>>>>
>>>> In the future it would be great if you could only post to one
>>>> mailing
>>>> list.
>>>>
>>>> I'm not sure what is wrong yet, however you should never try to set
>>>> the autocommit state of a connection that is enlisted in a jta
>>>> transaction. Enlisting and delisting the XAConnection will result
>>>> in
>>>> the autocommit being dealt with properly. The value from
>>>> getAutoCommit may or may not be meaningful in a jta transaction.
>>>> Outside a jta transaction the autocommit state defaults to true.
>>>> I'm
>>>> quite surprised you didn't get a more informative error.
>>>>
>>>> One important piece of information that I don't see is which tranql
>>>> wrapper you used to deploy your datasource.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Dec 29, 2009, at 3:48 AM, xuhongbo wrote:
>>>>
>>>>> Hi:
>>>>> Yet I haven't find the real reason , I have noticed another
>>>>> thing
>>>>> about the problem;
>>>>> The original test program will throw exception while
>>>>> transaction
>>>>> commit; but if I comment the statement
>>>>> "connection.setAutoCommit(false); ".
>>>>> the exception will throws while execute prepare statement; and
>>>>> exception
>>>>> changed as "ORA-02089: COMMIT doesn't allowed in sub transaction"
>>>>> which
>>>>> raised by oracle's driver;
>>>>> It seems the connection 's auto commit is default set to
>>>>> true; so I
>>>>> am wondering while secondly execute the trasaction , a no-
>>>>> transaction data
>>>>> source (not a transactional-datasource) is returned?
>>>>>
>>>>> -----origin-----
>>>>> Sender: xuhongbo [mailto:xuhb@tongtech.com]
>>>>> Date: 2009/12/29 12:53
>>>>> Receiver: dev@geronimo.apache.org
>>>>> CC: user@geronimo.apache.org
>>>>> Subject: Cannot using Geronimo to execute bean-managed transaction
>>>>> with
>>>>> oracle transaction more than once, but Glassfish does
>>>>>
>>>>> Hi:
>>>>> When I using bean managed transaction with oracle-xa , I
>>>>> found
>>> that
>>>>> it cannot execute more than once; the first time, things is right
>>>>> and
>>>>> database is update; but if execute once again a oracle- xa-warning
>>>>> and a
>>>>> Geronimo exception occurs; the warning and exception is list at the
>>>>> end of
>>>>> this mail;
>>>>>
>>>>> The Geronimo Version I used is 2.1.4; and oracle version is
>>>>> 9i;
>>>>>
>>>>> I have use another app-server GlassFish test the same
>>>>> program, and
>>>>> it works well; My test program is list in the attachments:
>>>>> MyStatelessSessionBean.java is the ejb, and MyServlet is a servlet
>>>>> call the
>>>>> ejb;
>>>>>
>>>>> The oracle xa datasource 's plan is also list in
>>>>> attachments; I am
>>>>> not sure about if I miss configured the datasource some-where; but
>>>>> The
>>>>> datasource does works: I can test it and execute a query through
>>>>> the
>>>>> Geronimo's console;
>>>>>
>>>>> Although the oracle 's version is older, but I doesn't
>>>>> thinks the
>>>>> database is not compatible with Geronimo's XA process; To ensure
>>>>> this, I
>>>>> write a simple test case which use the Geronimo's Transaction
>>>>> Manager and
>>>>> Oralce's XA API directly; the simple test case works well; The
>>>>> simple test
>>>>> case is also list in the list;
>>>>> In the simple test case I doesn't use the UserTransaction but
>>>>> direct use the Geronimo's TransactionManager, because when
>>>>> debugging
>>>>> the
>>>>> my-application, I found the UserTransaction is provided by OpenEJB,
>>>>> and it
>>>>> just wrap the Geronimo's Transaction Manager;
>>>>>
>>>>> Finally , I guess if the tranql provided XADatasource is not
>>>>> compatible with my application. So I try the following calling
>>>>> sequence, but
>>>>> they both occurs same problem;
>>>>> 1:open-connection-->begin-trans-->do-update-->
>>> end-trans->close-conn
>>>>>
>>> 2:begin-trans-->open-connection-->do-update-->end-trans->close-conn;
>>>>> 3:begin-trans->open-connection-->do-update-->close-conn->end-
>>>>> trans;
>>>>>
>>>>> Now I have no idea about this problem, so I hope if anyone can
>>>>> help-me to check this problem
>>>>> Thanks for any-suggestion;
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> ===================================================================
>>>>> Orcla XA Warning is:
>>>>> 009-12-25 19:39:00,500 WARN [Transaction] Unable to enlist
>>>>> XAResource
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.WrapperNamedXAResource@1e7dc51,
>>>>> errorCode: -3
>>>>> oracle.jdbc.xa.OracleXAException
>>>>> at
>>>>> oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:
>>>>> 1157)
>>>>> at
>>>>> oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:
>>>>> 295)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.WrapperNamedXAResource.start(Wrapper
>>>>> NamedXAResource.java:86)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.TransactionImpl.enlistResource(Trans
>>>>> actionImpl.java:209)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.connector.outbound.TransactionEnlistingInterceptor.getCo
>>>>> nnection(TransactionEnlistingInterceptor.java:54)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.connector.outbound.TransactionCachingInterceptor.getConn
>>>>> ection(TransactionCachingInterceptor.java:87)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.connector.outbound.ConnectionHandleInterceptor.getConnec
>>>>> tion(ConnectionHandleInterceptor.java:43)
>>>>> .......
>>>>> at java.lang.Thread.run(Unknown Source)
>>>>>
>>>>> Geronimo Exception is:
>>>>> javax.transaction.RollbackException: Unable to commit: transaction
>>>>> marked
>>>>> for rollback
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.TransactionImpl.rollbackResourcesDur
>>>>> ingCommit(TransactionImpl.java:671)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.TransactionImpl.commit(TransactionIm
>>>>> pl.java:270)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.TransactionManagerImpl.commit(Transa
>>>>> ctionManagerImpl.java:250)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .openejb.core.CoreUserTransaction.commit(CoreUserTransaction.java:
>>>>> 62)
>>>>> at
>>>>> org.apache.openejb.core.BaseContext
>>>>> $UserTransactionWrapper.commit(BaseContex
>>>>> t.java:194)
>>>>> at
>>>>> sampleear
>>>>> .MyStatelessSessionBean.sayHello(MyStatelessSessionBean.java:40)
>>>>> ......
>>>>> at java.lang.Thread.run(Unknown Source)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
Re: Cannot using Geronimo to execute bean-managed transaction with oracle transaction more than once, but Glassfish does
Posted by ext2 <xu...@tongtech.com>.
If just reading code of Geronimo , it's hard to understand sometimes. after
building a debug-able environment and tracking the source code of Geronimo
at run-time, things will be clearly.
-----origin-----
Sender: ext2 [mailto:xuhb@tongtech.com]
Date: 2010/1/11 14:57
Receiver: user@geronimo.apache.org
Subject: Re: Cannot using Geronimo to execute bean-managed transaction with
oracle transaction more than once, but Glassfish does
>>I see that ManagedXAConnection will set autoCommit to false in
>>localTransactionStart(). So you mean Geronimo is enlisting the resouce
>>before it starts the local transaction?
>>I see ManagedXAConnection also sets autoCommit to true in
>>localTransactionCommit() and localTransactionRollback(), so it's not
>>only the cleanup() method.
While using JTA , the Geronimo do nothing with localTransaction; The
localTransaction only works when using in non-jta transaction.
No matter the database 's driver support xa or no-xa, the data source can be
configured to use in jta transaction or in No-jta transaction;
-----origin-----
发件人: Jack Cai [mailto:greensight@gmail.com]
发送时间: 2010年1月11日 11:42
收件人: user@geronimo.apache.org
主题: Re: Cannot using Geronimo to execute bean-managed transaction with
oracle transaction more than once, but Glassfish does
I see that ManagedXAConnection will set autoCommit to false in
localTransactionStart(). So you mean Geronimo is enlisting the resouce
before it starts the local transaction?
I see ManagedXAConnection also sets autoCommit to true in
localTransactionCommit() and localTransactionRollback(), so it's not
only the cleanup() method.
-Jack
On Thu, Jan 7, 2010 at 8:42 PM, ext2 <xu...@tongtech.com> wrote:
> Hi David Jeck:
>
> If the tranql's oracle wrapper is changed, the oracle will works well. And
> user doesn't need write to a un-usual program at application level;
>
> Although I am still not agree to the Geronimo 's current action, but
anyway
> it's just another design strategy: now the database vendor has some
trivial
> difference , so the middle-ware (application-server) should has the
> responsible to shield the difference and always give a consistence
> appearance to the end-user; That's the strategy I finally decide to use
in
> my work (it's not a app-server, but still provide jta features);
>
> Best regard
> Ext2
> -----Origin-----
> Sender: David Jencks [mailto:david_jencks@yahoo.com]
> Date: 2010-1-7 17:23
> Receiver: user@geronimo.apache.org
> Subject: Re: Cannot using Geronimo to execute bean-managed transaction
with
> oracle transaction more than once, but Glassfish does
>
>
> On Jan 6, 2010, at 11:21 PM, ext2 wrote:
>
>> Hi, David Jeck:
>>
>> Sorry , I forget to said
>>> or, does the connection have to have auto commit set to true or set
>>> to
>>> false (which one)?
>> At the point of JTA's view, set auto commit has no other means, so
>> we need
>> not affect it and read it while using JTA; this works for most
>> database in
>> Geronimo, But oracle whose usage is different, only because of a
>> bug of
>> tranql. At application level ,we can only to resole the bug in a un-
>> usual
>> way.
>
> As I said, I haven't read the spec in several years, but I think this
> is a bug in oracle. My recollection is that the autocommit state is
> supposed to be ignored when enlisting in a JTA transaction. There
> are other oracle bugs related to autocommit, for instance the spec
> clearly says that (using local transactions) if autocommit is false,
> setting it to true should commit pending work, but oracle does not.
>
>>
>> Although setting auto commit has no other means in JTA, but this
>> doesn't
>> means the application-server has no responsible to check it.
>
> My recollection of the spec is that the app server has no need to
> check the autocommit state since enlisting in a jta transaction should
> cause the autocommit state to be ignored no matter what it is.
>
>> And that is
>> what I doest agree to Geronimo 's current action;
>
> We can probably fix this in the tranql oracle wrapper. Geronimo
> doesn't even know that it's dealing with a jdbc driver, so it has no
> knowledge of the autocommit property's existence.
>
> thanks
> david jencks
>
>>
>> -----Origin-----
>> Sender: David Jencks [mailto:david_jencks@yahoo.com]
>> Date: 2010-1-7 2:03
>> Receiver: user@geronimo.apache.org
>> Subject: Re: Cannot using Geronimo to execute bean-managed
>> transaction with
>> oracle transaction more than once, but Glassfish does
>>
>>
>> On Jan 6, 2010, at 3:05 AM, ext2 wrote:
>>
>>> The problem is caused by tranql-commons-connector is not compatible
>>> with
>>> Oracle 9i 's XA API. The details things happened as following
>>> description.
>>>
>>> When the XA transaction finished, the ManagedXAConnection(tranql)
>>> will be
>>> cleanup and put back to the pool. While cleanup the
>>> ManagedXAConnection,
>>> tranql reset the associated physical connection 's auto commit to
>>> true.
>>> Because at this time, Transaction Manager has finished the XA
>>> transaction,
>>> so reset the commit to true will acceptable by Oralce's XA driver;
>>>
>>> So unfortunately this will cause the XA resource cannot be enlist
>>> into
>>> transaction next time. and you can only execute the xa-transaction
>>> only
>>> once;
>>
>> It's been a long time since I looked into this, but if I remember the
>> spec correctly oracle's driver is not spec compliant here. I'm not
>> sure I understand exactly what sequences of operations are allowed by
>> oracle and which are not.
>>
>> if you call setAutocommit on a connection, either true or false, does
>> that prevent the associated managed connection from ever being
>> enlisted in an XA transaction?
>>
>> or, does the connection have to have autocommit set to true or set to
>> false (which one)?
>>
>> I don't have an easy way to set up oracle here to investigate this for
>> myself, I hope I'm asking my questions clearly enough to be
>> understood.
>>
>> thanks
>> david jencks
>>
>>
>>>
>>> -----Original -----
>>> Sender: xuhongbo [mailto:xuhb@tongtech.com]
>>> Date: 2009-12-30 17:15
>>> Receiver: user@geronimo.apache.org
>>> Subject: Re: Reply: Cannot using Geronimo to execute bean-managed
>>> transaction with oracle transaction more than once, but Glassfish
>>> does
>>>
>>> Hi Jack Cai:
>>>
>>> I have tried, the "tranql-connector-oracle-local" is ok, but it
>>> doesn't use
>>> xa transaction in jta, and use a faked Local-XAResource instead of
>>> real
>>> oracle-xa-resource;
>>>
>>> I am sorry to mis-understand your means and give the run-time class
>>> name in
>>> my previous reply; The error occurred program is just using "
>>> tranql-connector-oracle-xa"
>>>
>>> Additionally, I have try another Mysql database and using "
>>> tranql-connector-mysql-xa" do real xa transaction. It works well.
>>>
>>> So my mind changed, maybe there is something not compatible with
>>> oracle 9i
>>> database; In my original mail, I have post a very simple program
>>> which use
>>> the Geronimo Transaction Manager and Oracle XA API directly, this
>>> works
>>> well;
>>>
>>> Because tranql resource adaptor is a very simple wrapper , Geronimo
>>> does
>>> additional things to wrap the database connection (etc control
>>> pooling,
>>> xa-resource wrap, xa-resource cache for transaction-manager ...) ,
>>> so I am
>>> wondering if there is some other un-excepted database operation has
>>> been
>>> done and cause this problem? for convenience I post the simple
>>> program
>>> again.
>>>
>>> If we only concern database operation, does this simple program done
>>> exactly like the Geronimo done ? Or it doesn't , Geronimo do
>>> additional
>>> things... maybe the difference will be the real reason cause the
>>> problem;
>>> I have tracked at runtime, but unfortunately has not find some
>>> difference
>>> yet...
>>>
>>> Thanks a lot
>>> xuhongbo
>>>
>>>
>>> -----origin-----
>>> sender: Jack Cai [mailto:greensight@gmail.com]
>>> date: 2009/12/30 11:45
>>> receiver: user@geronimo.apache.org
>>> subject: Re: Reply: Cannot using Geronimo to execute bean-managed
>>> transaction with oracle transaction more than once, but Glassfish
>>> does
>>>
>>> Can you try to use the tranql-connector-oracle-xa or
>>> tranql-connector-oracle-local to do the test?
>>>
>>> -Jack
>>>
>>> On Wed, Dec 30, 2009 at 11:26 AM, xuhongbo <xu...@tongtech.com> wrote:
>>>>
>>>>>> In the future it would be great if you could only post to one
>>>>>> mailing
>>>>>> list.
>>>> Thanks, I know
>>>>
>>>>>> I'm not sure what is wrong yet, however you should never try to
>>>>>> set
>>>>>> the autocommit state of a connection that is enlisted in a jta
>>>>>> transaction. Enlisting and delisting the XAConnection will
>>>>>> result in
>>>>>> the autocommit being dealt with properly. The value from
>>>>>> getAutoCommit may or may not be meaningful in a jta transaction.
>>>>>> Outside a jta transaction the autocommit state defaults to true.
>>>>>> I'm
>>>>>> quite surprised you didn't get a more informative error.
>>>>
>>>> Yes you are right, auto commit has no means for jta connection and
>>>> cannot
>>> be
>>>> set to true; here I just set auto commit to false, so a jta
>>>> connection
>>>> should just omit it;
>>>> But the surprise thing is if I doesn't affect auto commit state(in
>>>> the
>>>> program, just comment the statement "setAutocommit(false)"), when
>>>> execute
>>>> database operation, a "ORA-02089: COMMIT ..." exception will be
>>>> throwed
>>> by
>>>> oracle's database driver; it looks like the Geronimo does a wrong
>>>> things
>>>> "commit on the connection when execute database operation"; and this
>>> should
>>>> only occurs on non-jta connection, because only no-jta connection
>>>> will set
>>>> auto commit default to true.
>>>>
>>>>>> One important piece of information that I don't see is which
>>>>>> tranql
>>>>>> wrapper you used to deploy your datasource.
>>>>
>>>> The datasource is org.tranql.connector.jdbc.DataSource. And it
>>>> use a a
>>>> managed-connection factory " org.tranql.connector.oracle.XAMCF" to
>>>> open
>>>> connection; And the managed-connection factory use a oracle's xa
>>> datasource
>>>> (oracle.jdbc.xa.client.OracleXADataSource);
>>>>
>>>> By the way , I haven't ever post a trivial problem I have meet
>>>> when I
>>> deploy
>>>> the Oracle-XA data source. The trivial thing is: I must change the
>>>> deploy
>>>> plan created by Geronimo's web manage console tools, delete the
>>>> empty
>>>> property "TNSEntryName" and manually deploy it; because this is the
>>> oracle9i
>>>> database driver's question --- "a empty string value(not a null
>>>> value) set
>>>> to TNSEntryName" will cause oracle9i's database driver to omit the
>>>> other
>>>> property (etc serverName, serviceName ...) and cannot establish a
>>>> connect
>>> ;
>>>> I thinks this should have no means to the transaction commit
>>>> failure; but
>>>> maybe it would give some other useful things help to find out the
>>>> reason.
>>>>
>>>> Thanks a lot
>>>> xuhongbo
>>>>
>>>> -----origin -----
>>>> sender: David Jencks [mailto:david_jencks@yahoo.com]
>>>> date: 2009/12/30 1:43
>>>> receiver: user@geronimo.apache.org
>>>> subject: Re: Reply: Cannot using Geronimo to execute bean-managed
>>>> transaction with oracle transaction more than once, but Glassfish
>>>> does
>>>>
>>>> In the future it would be great if you could only post to one
>>>> mailing
>>>> list.
>>>>
>>>> I'm not sure what is wrong yet, however you should never try to set
>>>> the autocommit state of a connection that is enlisted in a jta
>>>> transaction. Enlisting and delisting the XAConnection will result
>>>> in
>>>> the autocommit being dealt with properly. The value from
>>>> getAutoCommit may or may not be meaningful in a jta transaction.
>>>> Outside a jta transaction the autocommit state defaults to true.
>>>> I'm
>>>> quite surprised you didn't get a more informative error.
>>>>
>>>> One important piece of information that I don't see is which tranql
>>>> wrapper you used to deploy your datasource.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Dec 29, 2009, at 3:48 AM, xuhongbo wrote:
>>>>
>>>>> Hi:
>>>>> Yet I haven't find the real reason , I have noticed another
>>>>> thing
>>>>> about the problem;
>>>>> The original test program will throw exception while
>>>>> transaction
>>>>> commit; but if I comment the statement
>>>>> "connection.setAutoCommit(false); ".
>>>>> the exception will throws while execute prepare statement; and
>>>>> exception
>>>>> changed as "ORA-02089: COMMIT doesn't allowed in sub transaction"
>>>>> which
>>>>> raised by oracle's driver;
>>>>> It seems the connection 's auto commit is default set to
>>>>> true; so I
>>>>> am wondering while secondly execute the trasaction , a no-
>>>>> transaction data
>>>>> source (not a transactional-datasource) is returned?
>>>>>
>>>>> -----origin-----
>>>>> Sender: xuhongbo [mailto:xuhb@tongtech.com]
>>>>> Date: 2009/12/29 12:53
>>>>> Receiver: dev@geronimo.apache.org
>>>>> CC: user@geronimo.apache.org
>>>>> Subject: Cannot using Geronimo to execute bean-managed transaction
>>>>> with
>>>>> oracle transaction more than once, but Glassfish does
>>>>>
>>>>> Hi:
>>>>> When I using bean managed transaction with oracle-xa , I
>>>>> found
>>> that
>>>>> it cannot execute more than once; the first time, things is right
>>>>> and
>>>>> database is update; but if execute once again a oracle- xa-warning
>>>>> and a
>>>>> Geronimo exception occurs; the warning and exception is list at the
>>>>> end of
>>>>> this mail;
>>>>>
>>>>> The Geronimo Version I used is 2.1.4; and oracle version is
>>>>> 9i;
>>>>>
>>>>> I have use another app-server GlassFish test the same
>>>>> program, and
>>>>> it works well; My test program is list in the attachments:
>>>>> MyStatelessSessionBean.java is the ejb, and MyServlet is a servlet
>>>>> call the
>>>>> ejb;
>>>>>
>>>>> The oracle xa datasource 's plan is also list in
>>>>> attachments; I am
>>>>> not sure about if I miss configured the datasource some-where; but
>>>>> The
>>>>> datasource does works: I can test it and execute a query through
>>>>> the
>>>>> Geronimo's console;
>>>>>
>>>>> Although the oracle 's version is older, but I doesn't
>>>>> thinks the
>>>>> database is not compatible with Geronimo's XA process; To ensure
>>>>> this, I
>>>>> write a simple test case which use the Geronimo's Transaction
>>>>> Manager and
>>>>> Oralce's XA API directly; the simple test case works well; The
>>>>> simple test
>>>>> case is also list in the list;
>>>>> In the simple test case I doesn't use the UserTransaction but
>>>>> direct use the Geronimo's TransactionManager, because when
>>>>> debugging
>>>>> the
>>>>> my-application, I found the UserTransaction is provided by OpenEJB,
>>>>> and it
>>>>> just wrap the Geronimo's Transaction Manager;
>>>>>
>>>>> Finally , I guess if the tranql provided XADatasource is not
>>>>> compatible with my application. So I try the following calling
>>>>> sequence, but
>>>>> they both occurs same problem;
>>>>> 1:open-connection-->begin-trans-->do-update-->
>>> end-trans->close-conn
>>>>>
>>> 2:begin-trans-->open-connection-->do-update-->end-trans->close-conn;
>>>>> 3:begin-trans->open-connection-->do-update-->close-conn->end-
>>>>> trans;
>>>>>
>>>>> Now I have no idea about this problem, so I hope if anyone can
>>>>> help-me to check this problem
>>>>> Thanks for any-suggestion;
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> ===================================================================
>>>>> Orcla XA Warning is:
>>>>> 009-12-25 19:39:00,500 WARN [Transaction] Unable to enlist
>>>>> XAResource
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.WrapperNamedXAResource@1e7dc51,
>>>>> errorCode: -3
>>>>> oracle.jdbc.xa.OracleXAException
>>>>> at
>>>>> oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:
>>>>> 1157)
>>>>> at
>>>>> oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:
>>>>> 295)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.WrapperNamedXAResource.start(Wrapper
>>>>> NamedXAResource.java:86)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.TransactionImpl.enlistResource(Trans
>>>>> actionImpl.java:209)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.connector.outbound.TransactionEnlistingInterceptor.getCo
>>>>> nnection(TransactionEnlistingInterceptor.java:54)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.connector.outbound.TransactionCachingInterceptor.getConn
>>>>> ection(TransactionCachingInterceptor.java:87)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.connector.outbound.ConnectionHandleInterceptor.getConnec
>>>>> tion(ConnectionHandleInterceptor.java:43)
>>>>> .......
>>>>> at java.lang.Thread.run(Unknown Source)
>>>>>
>>>>> Geronimo Exception is:
>>>>> javax.transaction.RollbackException: Unable to commit: transaction
>>>>> marked
>>>>> for rollback
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.TransactionImpl.rollbackResourcesDur
>>>>> ingCommit(TransactionImpl.java:671)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.TransactionImpl.commit(TransactionIm
>>>>> pl.java:270)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.TransactionManagerImpl.commit(Transa
>>>>> ctionManagerImpl.java:250)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .openejb.core.CoreUserTransaction.commit(CoreUserTransaction.java:
>>>>> 62)
>>>>> at
>>>>> org.apache.openejb.core.BaseContext
>>>>> $UserTransactionWrapper.commit(BaseContex
>>>>> t.java:194)
>>>>> at
>>>>> sampleear
>>>>> .MyStatelessSessionBean.sayHello(MyStatelessSessionBean.java:40)
>>>>> ......
>>>>> at java.lang.Thread.run(Unknown Source)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
答复: Cannot using Geronimo to execute bean-managed transaction with oracle transaction more than once, but Glassfish does
Posted by ext2 <xu...@tongtech.com>.
>>I see that ManagedXAConnection will set autoCommit to false in
>>localTransactionStart(). So you mean Geronimo is enlisting the resouce
>>before it starts the local transaction?
>>I see ManagedXAConnection also sets autoCommit to true in
>>localTransactionCommit() and localTransactionRollback(), so it's not
>>only the cleanup() method.
While using JTA , the Geronimo do nothing with localTransaction; The localTransaction only works when using in non-jta transaction.
No matter the database 's driver support xa or no-xa, the data source can be configured to use in jta transaction or in No-jta transaction;
-----origin-----
发件人: Jack Cai [mailto:greensight@gmail.com]
发送时间: 2010年1月11日 11:42
收件人: user@geronimo.apache.org
主题: Re: Cannot using Geronimo to execute bean-managed transaction with oracle transaction more than once, but Glassfish does
I see that ManagedXAConnection will set autoCommit to false in
localTransactionStart(). So you mean Geronimo is enlisting the resouce
before it starts the local transaction?
I see ManagedXAConnection also sets autoCommit to true in
localTransactionCommit() and localTransactionRollback(), so it's not
only the cleanup() method.
-Jack
On Thu, Jan 7, 2010 at 8:42 PM, ext2 <xu...@tongtech.com> wrote:
> Hi David Jeck:
>
> If the tranql's oracle wrapper is changed, the oracle will works well. And
> user doesn't need write to a un-usual program at application level;
>
> Although I am still not agree to the Geronimo 's current action, but anyway
> it's just another design strategy: now the database vendor has some trivial
> difference , so the middle-ware (application-server) should has the
> responsible to shield the difference and always give a consistence
> appearance to the end-user; That's the strategy I finally decide to use in
> my work (it's not a app-server, but still provide jta features);
>
> Best regard
> Ext2
> -----Origin-----
> Sender: David Jencks [mailto:david_jencks@yahoo.com]
> Date: 2010-1-7 17:23
> Receiver: user@geronimo.apache.org
> Subject: Re: Cannot using Geronimo to execute bean-managed transaction with
> oracle transaction more than once, but Glassfish does
>
>
> On Jan 6, 2010, at 11:21 PM, ext2 wrote:
>
>> Hi, David Jeck:
>>
>> Sorry , I forget to said
>>> or, does the connection have to have auto commit set to true or set
>>> to
>>> false (which one)?
>> At the point of JTA's view, set auto commit has no other means, so
>> we need
>> not affect it and read it while using JTA; this works for most
>> database in
>> Geronimo, But oracle whose usage is different, only because of a
>> bug of
>> tranql. At application level ,we can only to resole the bug in a un-
>> usual
>> way.
>
> As I said, I haven't read the spec in several years, but I think this
> is a bug in oracle. My recollection is that the autocommit state is
> supposed to be ignored when enlisting in a JTA transaction. There
> are other oracle bugs related to autocommit, for instance the spec
> clearly says that (using local transactions) if autocommit is false,
> setting it to true should commit pending work, but oracle does not.
>
>>
>> Although setting auto commit has no other means in JTA, but this
>> doesn't
>> means the application-server has no responsible to check it.
>
> My recollection of the spec is that the app server has no need to
> check the autocommit state since enlisting in a jta transaction should
> cause the autocommit state to be ignored no matter what it is.
>
>> And that is
>> what I doest agree to Geronimo 's current action;
>
> We can probably fix this in the tranql oracle wrapper. Geronimo
> doesn't even know that it's dealing with a jdbc driver, so it has no
> knowledge of the autocommit property's existence.
>
> thanks
> david jencks
>
>>
>> -----Origin-----
>> Sender: David Jencks [mailto:david_jencks@yahoo.com]
>> Date: 2010-1-7 2:03
>> Receiver: user@geronimo.apache.org
>> Subject: Re: Cannot using Geronimo to execute bean-managed
>> transaction with
>> oracle transaction more than once, but Glassfish does
>>
>>
>> On Jan 6, 2010, at 3:05 AM, ext2 wrote:
>>
>>> The problem is caused by tranql-commons-connector is not compatible
>>> with
>>> Oracle 9i 's XA API. The details things happened as following
>>> description.
>>>
>>> When the XA transaction finished, the ManagedXAConnection(tranql)
>>> will be
>>> cleanup and put back to the pool. While cleanup the
>>> ManagedXAConnection,
>>> tranql reset the associated physical connection 's auto commit to
>>> true.
>>> Because at this time, Transaction Manager has finished the XA
>>> transaction,
>>> so reset the commit to true will acceptable by Oralce's XA driver;
>>>
>>> So unfortunately this will cause the XA resource cannot be enlist
>>> into
>>> transaction next time. and you can only execute the xa-transaction
>>> only
>>> once;
>>
>> It's been a long time since I looked into this, but if I remember the
>> spec correctly oracle's driver is not spec compliant here. I'm not
>> sure I understand exactly what sequences of operations are allowed by
>> oracle and which are not.
>>
>> if you call setAutocommit on a connection, either true or false, does
>> that prevent the associated managed connection from ever being
>> enlisted in an XA transaction?
>>
>> or, does the connection have to have autocommit set to true or set to
>> false (which one)?
>>
>> I don't have an easy way to set up oracle here to investigate this for
>> myself, I hope I'm asking my questions clearly enough to be
>> understood.
>>
>> thanks
>> david jencks
>>
>>
>>>
>>> -----Original -----
>>> Sender: xuhongbo [mailto:xuhb@tongtech.com]
>>> Date: 2009-12-30 17:15
>>> Receiver: user@geronimo.apache.org
>>> Subject: Re: Reply: Cannot using Geronimo to execute bean-managed
>>> transaction with oracle transaction more than once, but Glassfish
>>> does
>>>
>>> Hi Jack Cai:
>>>
>>> I have tried, the "tranql-connector-oracle-local" is ok, but it
>>> doesn't use
>>> xa transaction in jta, and use a faked Local-XAResource instead of
>>> real
>>> oracle-xa-resource;
>>>
>>> I am sorry to mis-understand your means and give the run-time class
>>> name in
>>> my previous reply; The error occurred program is just using "
>>> tranql-connector-oracle-xa"
>>>
>>> Additionally, I have try another Mysql database and using "
>>> tranql-connector-mysql-xa" do real xa transaction. It works well.
>>>
>>> So my mind changed, maybe there is something not compatible with
>>> oracle 9i
>>> database; In my original mail, I have post a very simple program
>>> which use
>>> the Geronimo Transaction Manager and Oracle XA API directly, this
>>> works
>>> well;
>>>
>>> Because tranql resource adaptor is a very simple wrapper , Geronimo
>>> does
>>> additional things to wrap the database connection (etc control
>>> pooling,
>>> xa-resource wrap, xa-resource cache for transaction-manager ...) ,
>>> so I am
>>> wondering if there is some other un-excepted database operation has
>>> been
>>> done and cause this problem? for convenience I post the simple
>>> program
>>> again.
>>>
>>> If we only concern database operation, does this simple program done
>>> exactly like the Geronimo done ? Or it doesn't , Geronimo do
>>> additional
>>> things... maybe the difference will be the real reason cause the
>>> problem;
>>> I have tracked at runtime, but unfortunately has not find some
>>> difference
>>> yet...
>>>
>>> Thanks a lot
>>> xuhongbo
>>>
>>>
>>> -----origin-----
>>> sender: Jack Cai [mailto:greensight@gmail.com]
>>> date: 2009/12/30 11:45
>>> receiver: user@geronimo.apache.org
>>> subject: Re: Reply: Cannot using Geronimo to execute bean-managed
>>> transaction with oracle transaction more than once, but Glassfish
>>> does
>>>
>>> Can you try to use the tranql-connector-oracle-xa or
>>> tranql-connector-oracle-local to do the test?
>>>
>>> -Jack
>>>
>>> On Wed, Dec 30, 2009 at 11:26 AM, xuhongbo <xu...@tongtech.com> wrote:
>>>>
>>>>>> In the future it would be great if you could only post to one
>>>>>> mailing
>>>>>> list.
>>>> Thanks, I know
>>>>
>>>>>> I'm not sure what is wrong yet, however you should never try to
>>>>>> set
>>>>>> the autocommit state of a connection that is enlisted in a jta
>>>>>> transaction. Enlisting and delisting the XAConnection will
>>>>>> result in
>>>>>> the autocommit being dealt with properly. The value from
>>>>>> getAutoCommit may or may not be meaningful in a jta transaction.
>>>>>> Outside a jta transaction the autocommit state defaults to true.
>>>>>> I'm
>>>>>> quite surprised you didn't get a more informative error.
>>>>
>>>> Yes you are right, auto commit has no means for jta connection and
>>>> cannot
>>> be
>>>> set to true; here I just set auto commit to false, so a jta
>>>> connection
>>>> should just omit it;
>>>> But the surprise thing is if I doesn't affect auto commit state(in
>>>> the
>>>> program, just comment the statement "setAutocommit(false)"), when
>>>> execute
>>>> database operation, a "ORA-02089: COMMIT ..." exception will be
>>>> throwed
>>> by
>>>> oracle's database driver; it looks like the Geronimo does a wrong
>>>> things
>>>> "commit on the connection when execute database operation"; and this
>>> should
>>>> only occurs on non-jta connection, because only no-jta connection
>>>> will set
>>>> auto commit default to true.
>>>>
>>>>>> One important piece of information that I don't see is which
>>>>>> tranql
>>>>>> wrapper you used to deploy your datasource.
>>>>
>>>> The datasource is org.tranql.connector.jdbc.DataSource. And it
>>>> use a a
>>>> managed-connection factory " org.tranql.connector.oracle.XAMCF" to
>>>> open
>>>> connection; And the managed-connection factory use a oracle's xa
>>> datasource
>>>> (oracle.jdbc.xa.client.OracleXADataSource);
>>>>
>>>> By the way , I haven't ever post a trivial problem I have meet
>>>> when I
>>> deploy
>>>> the Oracle-XA data source. The trivial thing is: I must change the
>>>> deploy
>>>> plan created by Geronimo's web manage console tools, delete the
>>>> empty
>>>> property "TNSEntryName" and manually deploy it; because this is the
>>> oracle9i
>>>> database driver's question --- "a empty string value(not a null
>>>> value) set
>>>> to TNSEntryName" will cause oracle9i's database driver to omit the
>>>> other
>>>> property (etc serverName, serviceName ...) and cannot establish a
>>>> connect
>>> ;
>>>> I thinks this should have no means to the transaction commit
>>>> failure; but
>>>> maybe it would give some other useful things help to find out the
>>>> reason.
>>>>
>>>> Thanks a lot
>>>> xuhongbo
>>>>
>>>> -----origin -----
>>>> sender: David Jencks [mailto:david_jencks@yahoo.com]
>>>> date: 2009/12/30 1:43
>>>> receiver: user@geronimo.apache.org
>>>> subject: Re: Reply: Cannot using Geronimo to execute bean-managed
>>>> transaction with oracle transaction more than once, but Glassfish
>>>> does
>>>>
>>>> In the future it would be great if you could only post to one
>>>> mailing
>>>> list.
>>>>
>>>> I'm not sure what is wrong yet, however you should never try to set
>>>> the autocommit state of a connection that is enlisted in a jta
>>>> transaction. Enlisting and delisting the XAConnection will result
>>>> in
>>>> the autocommit being dealt with properly. The value from
>>>> getAutoCommit may or may not be meaningful in a jta transaction.
>>>> Outside a jta transaction the autocommit state defaults to true.
>>>> I'm
>>>> quite surprised you didn't get a more informative error.
>>>>
>>>> One important piece of information that I don't see is which tranql
>>>> wrapper you used to deploy your datasource.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Dec 29, 2009, at 3:48 AM, xuhongbo wrote:
>>>>
>>>>> Hi:
>>>>> Yet I haven't find the real reason , I have noticed another
>>>>> thing
>>>>> about the problem;
>>>>> The original test program will throw exception while
>>>>> transaction
>>>>> commit; but if I comment the statement
>>>>> "connection.setAutoCommit(false); ".
>>>>> the exception will throws while execute prepare statement; and
>>>>> exception
>>>>> changed as "ORA-02089: COMMIT doesn't allowed in sub transaction"
>>>>> which
>>>>> raised by oracle's driver;
>>>>> It seems the connection 's auto commit is default set to
>>>>> true; so I
>>>>> am wondering while secondly execute the trasaction , a no-
>>>>> transaction data
>>>>> source (not a transactional-datasource) is returned?
>>>>>
>>>>> -----origin-----
>>>>> Sender: xuhongbo [mailto:xuhb@tongtech.com]
>>>>> Date: 2009/12/29 12:53
>>>>> Receiver: dev@geronimo.apache.org
>>>>> CC: user@geronimo.apache.org
>>>>> Subject: Cannot using Geronimo to execute bean-managed transaction
>>>>> with
>>>>> oracle transaction more than once, but Glassfish does
>>>>>
>>>>> Hi:
>>>>> When I using bean managed transaction with oracle-xa , I
>>>>> found
>>> that
>>>>> it cannot execute more than once; the first time, things is right
>>>>> and
>>>>> database is update; but if execute once again a oracle- xa-warning
>>>>> and a
>>>>> Geronimo exception occurs; the warning and exception is list at the
>>>>> end of
>>>>> this mail;
>>>>>
>>>>> The Geronimo Version I used is 2.1.4; and oracle version is
>>>>> 9i;
>>>>>
>>>>> I have use another app-server GlassFish test the same
>>>>> program, and
>>>>> it works well; My test program is list in the attachments:
>>>>> MyStatelessSessionBean.java is the ejb, and MyServlet is a servlet
>>>>> call the
>>>>> ejb;
>>>>>
>>>>> The oracle xa datasource 's plan is also list in
>>>>> attachments; I am
>>>>> not sure about if I miss configured the datasource some-where; but
>>>>> The
>>>>> datasource does works: I can test it and execute a query through
>>>>> the
>>>>> Geronimo's console;
>>>>>
>>>>> Although the oracle 's version is older, but I doesn't
>>>>> thinks the
>>>>> database is not compatible with Geronimo's XA process; To ensure
>>>>> this, I
>>>>> write a simple test case which use the Geronimo's Transaction
>>>>> Manager and
>>>>> Oralce's XA API directly; the simple test case works well; The
>>>>> simple test
>>>>> case is also list in the list;
>>>>> In the simple test case I doesn't use the UserTransaction but
>>>>> direct use the Geronimo's TransactionManager, because when
>>>>> debugging
>>>>> the
>>>>> my-application, I found the UserTransaction is provided by OpenEJB,
>>>>> and it
>>>>> just wrap the Geronimo's Transaction Manager;
>>>>>
>>>>> Finally , I guess if the tranql provided XADatasource is not
>>>>> compatible with my application. So I try the following calling
>>>>> sequence, but
>>>>> they both occurs same problem;
>>>>> 1:open-connection-->begin-trans-->do-update-->
>>> end-trans->close-conn
>>>>>
>>> 2:begin-trans-->open-connection-->do-update-->end-trans->close-conn;
>>>>> 3:begin-trans->open-connection-->do-update-->close-conn->end-
>>>>> trans;
>>>>>
>>>>> Now I have no idea about this problem, so I hope if anyone can
>>>>> help-me to check this problem
>>>>> Thanks for any-suggestion;
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> =
>>>>> ===================================================================
>>>>> Orcla XA Warning is:
>>>>> 009-12-25 19:39:00,500 WARN [Transaction] Unable to enlist
>>>>> XAResource
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.WrapperNamedXAResource@1e7dc51,
>>>>> errorCode: -3
>>>>> oracle.jdbc.xa.OracleXAException
>>>>> at
>>>>> oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:
>>>>> 1157)
>>>>> at
>>>>> oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:
>>>>> 295)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.WrapperNamedXAResource.start(Wrapper
>>>>> NamedXAResource.java:86)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.TransactionImpl.enlistResource(Trans
>>>>> actionImpl.java:209)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.connector.outbound.TransactionEnlistingInterceptor.getCo
>>>>> nnection(TransactionEnlistingInterceptor.java:54)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.connector.outbound.TransactionCachingInterceptor.getConn
>>>>> ection(TransactionCachingInterceptor.java:87)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.connector.outbound.ConnectionHandleInterceptor.getConnec
>>>>> tion(ConnectionHandleInterceptor.java:43)
>>>>> .......
>>>>> at java.lang.Thread.run(Unknown Source)
>>>>>
>>>>> Geronimo Exception is:
>>>>> javax.transaction.RollbackException: Unable to commit: transaction
>>>>> marked
>>>>> for rollback
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.TransactionImpl.rollbackResourcesDur
>>>>> ingCommit(TransactionImpl.java:671)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.TransactionImpl.commit(TransactionIm
>>>>> pl.java:270)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .geronimo.transaction.manager.TransactionManagerImpl.commit(Transa
>>>>> ctionManagerImpl.java:250)
>>>>> at
>>>>> org
>>>>> .apache
>>>>> .openejb.core.CoreUserTransaction.commit(CoreUserTransaction.java:
>>>>> 62)
>>>>> at
>>>>> org.apache.openejb.core.BaseContext
>>>>> $UserTransactionWrapper.commit(BaseContex
>>>>> t.java:194)
>>>>> at
>>>>> sampleear
>>>>> .MyStatelessSessionBean.sayHello(MyStatelessSessionBean.java:40)
>>>>> ......
>>>>> at java.lang.Thread.run(Unknown Source)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>