Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@geronimo.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: "ext2" <xuhb@tongtech.com>
To: <user@geronimo.apache.org>
Subject: Re: Cannot using Geronimo to execute bean-managed transaction with
 oracle transaction more than once, but Glassfish does
Date: Thu, 7 Jan 2010 20:42:00 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <17699C49-CFD6-4012-B57F-A437FB7A9C90@yahoo.com>
Thread-Index: AcqPewt9aMMTEQ3FT3KP4hGWKAq76QAFbrUg
Message-Id: <20100107124233.942A2816018@nike.apache.org>

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 <xuhb@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)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
>