geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ruebsam <>
Subject Re: daytrader with Tranql Oracle XA resource adapter
Date Fri, 07 Jul 2006 15:52:25 GMT
Lin Sun wrote:
> Hi there,
> Thanks for the pointer!  IIUC, if the application uses connection.commit,
> tranql will translate that as setautocommit(true) when the
> commitBeforeAutoCommit is set to false.   I believe this is what I have in
> my environment.

TranQL use always setAutoCommit(true) no matter what you set in
commitBeforeAutoCommit. But if you set commitBeforeAutoCommit=true
TranQL calls a extra commit on the connection so that you can be sure
that it is done.

> However, I still don't understand why it makes such a big difference for
> Oracle.  I have loaded daytrader on another J2EE application server
> (WebSphere Application Server) and found out the same order committed to the
> oracle database right away.  With that, I would not categorize it as one of
> the problematic drivers you mentioned before.

maybe problematic in case of the setAutoCommit behavior


> Since derby and db2 XA adapter don't have this "delayed committing" problem
> at all, I compared the two Tranql vendors' code with the Oracle vendor code.
> Basically the vendor code contains the vendor specific MCF class that is
> created based on the datasource from the vendor (for example,
> OracleXADataSource).  The MCF also sets/gets the datasource's different
> properties (like databasename, username, password, servername, etc.).  I
> still don't get much clue as to why Oracle is special with Tranql.
> I think what I'll do is to come up with a simple application that can be
> loaded into Eclipse and step into the connection.commit() code from Eclipse.
> Too bad that I haven't figured out how to get daytrader running from
> Eclipse.:-(   
> Time to study the new plugin Sachin puts out.:-)
> Lin
> -----Original Message-----
> From: Mario Rübsam [] 
> Sent: Thursday, July 06, 2006 2:37 PM
> To:
> Subject: Re: daytrader with Tranql Oracle XA resource adapter
> Lin Sun wrote:
>> Hi there,
>> Do you know how to log the commits on the oracle side?  I 'll be happy to
>> check that out if I know how to do it.
> I don't have a clue about the Oracle tools. But there must be some admin
> tool to show the stats of the server, the connections, threads, ...
> There is normally a transaction counter in these tools. Another way to find
> it out is to look into the driver itself and figure out what is going on
> in the setAutoCommit() method. But this is not legal in every country for
> closed source interfaces.
>> I posted another note yesterday.   The application was not using
> AutoCommit.
>> Instead connection.commit() is being used.
> That is correct, but to commit the local transaction TranQL use the
> setAutoCommit(true); method, so if the JDBC driver is spec compliant the
> transaction must be commited ... so far the theory, in the real world
> some of the drivers don't do it for performance or whatever reasons.
> There was already a discussion about this problem here:
> Thanks,
> Mario
>> Lin
>> -----Original Message-----
>> From: Mario Rübsam [] 
>> Sent: Wednesday, July 05, 2006 4:59 PM
>> To:
>> Subject: Re: daytrader with Tranql Oracle XA resource adapter
>> I don't have experience with the Oracle Adapter. Can you log the commits
> on
>> the Oracle side to see if any commits come through? I had a similar
> problem
>> with MaxDB and it seems that the transactions are not closed because the
>> JDBC driver for MaxDB did no commit on the connection if the AutoCommit
> was
>> switched from false to true. The JDBC spec says if the value changed the
>> connection must be commited but the driver does not. Thats why I use
>> CommitBeforeAutCommit now.
>> Can you try to use the generic adapter to connect to Oracle and see if it
>> happens also?
>> Thanks,
>> Mario
>> Lin Sun wrote:
>>> Hi there,
>>> Thanks - I remember seeing your posting on CommitBeforeAutCommit setting
>> in
>>> the generic adapter.    The CommitBeforeAutCommit setting is not avail in
>>> the Oracle XA resource adapter.  
>>> Lin
>>> -----Original Message-----
>>> From: Mario Rübsam [] 
>>> Sent: Thursday, June 29, 2006 4:56 PM
>>> To:
>>> Subject: Re: daytrader with Tranql Oracle XA resource adapter
>>> Hi,
>>> the CommitBeforeAutCommit setting in the generic adapter call
>>> a commit on the local connection before it calls setAutoCommit(true).
>>> Some JDBC drivers act not like specified in JDBC and don't call
>>> a commit when the AutoCommit value changes with setAutoCommit(true)
>>> so CommitBeforeAutCommit is a workaround to get the transaction
>>> commited on these drivers (MySQL, MaxDB, PostgreSQL in some cases).
>>> I don't know about the XA driver and Oracle but it could be a similar
>>> problem.
>>> -Mario
>>> Lin Sun wrote:
>>>> Hi there,
>>>> I have been playing with the daytrader with Tranql Oracle XA resource
>>>> adapter (tranql-connector-oracle-xa-1.1.rar).  After I tweaked the
>>>> plan a bit and I am able to get daytrader running well with oracle!
>>>> One thing I noticed is that if I perform any trading activities as a
>>>> user (say uid:1, account_id 50), I get the message that my order has
>>>> been completed almost immediately.  However, the order isn't committed
>>>> into the oracle database until quite a while.  I don't know the exact
>>>> timing but seems to be over 20-30 minutes.
>>>> Here is what I did to check if the order is recorded in the database:
>>>> Select * from orderejb where account_id=50;
>>>> If the order is committed into the database, I would expect a row that
>>>> represents my previous order to be returned as the output of the sql
>>>> command.
>>>> If I run the same scenario with db2 or derby, I can see my order
>>>> recorded in the orderejb table immediately.
>>>> I looked at the tranql oracle vendor code but I didn't see anywhere
>>>> specifying the commit timing thing.  The generic resource adapter does
>>>> offer an param called CommitBeforeAutCommit and by setting it to true
>>>> would force the commit to happen immediately.   Can someone shed some
>>>> light on this?
>>>> Thanks, Lin

View raw message