Definition of Oracle XA datasources

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Definition of Oracle XA datasources

Chris Selwyn
I have just got to the bottom of why my customer's XA datasources have not been working...

It is a result of two things:-
  • They had not installed the JAVA_XA package in Oracle 11g
  • By default Oracle XA datasources explicitly set NativeXA=false
I realise that getting the customer to install the JAVA_XA package would solve the problem but according to the Oracle docs the native API is much quicker and, therefore, we would prefer to use it.

Is there a good reason why Glassfish defaults to setting NativeXA to false?
Is there a good reason why I should not either a) set it to true or b) remove the setting completely?

Any suggestions or insights welcome :-)

Chris
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Definition of Oracle XA datasources

Paul Peters

Hi Chris,

 

As far as I know this has been so for quite some years.. and it has to do with local transactions being a lot quicker and easier to use than global transactions. XA isn’t so common place when having quite some choice such as pessimistic locking, etcetera. For the same reason JAVA_XA isn’t installed by default.

NativeXA… haven’t fiddled around with that one yet, but I wonder, when the JVM has heated up, if it makes so much of a difference..

 

Take care

Paul

 

 

From: Chris Selwyn

 

I have just got to the bottom of why my customer's XA datasources have not been working...

It is a result of two things:-

  • They had not installed the JAVA_XA package in Oracle 11g
  • By default Oracle XA datasources explicitly set NativeXA=false

I realise that getting the customer to install the JAVA_XA package would solve the problem but according to the Oracle docs the native API is much quicker and, therefore, we would prefer to use it.

Is there a good reason why Glassfish defaults to setting NativeXA to false?
Is there a good reason why I should not either a) set it to true or b) remove the setting completely?

Any suggestions or insights welcome :-)

Chris

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Definition of Oracle XA datasources

Chris Selwyn
As far as I can tell the NativeXA flag only controls how XA transactions are communicated to the database... It does not control whether or not XA is being used.
JAVA_XA is not needed since Oracle 10g because the thin JDBC driver can use the native XA API.
But then the default Glassfish entry stops the JDBC driver from using the native API... Doesn't make sense to me.

Chris

On 26/01/2010 15:12, Paul Peters wrote:

Hi Chris,

 

As far as I know this has been so for quite some years.. and it has to do with local transactions being a lot quicker and easier to use than global transactions. XA isn’t so common place when having quite some choice such as pessimistic locking, etcetera. For the same reason JAVA_XA isn’t installed by default.

NativeXA… haven’t fiddled around with that one yet, but I wonder, when the JVM has heated up, if it makes so much of a difference..

 

Take care

Paul

 

 

From: Chris Selwyn

 

I have just got to the bottom of why my customer's XA datasources have not been working...

It is a result of two things:-

  • They had not installed the JAVA_XA package in Oracle 11g
  • By default Oracle XA datasources explicitly set NativeXA=false

I realise that getting the customer to install the JAVA_XA package would solve the problem but according to the Oracle docs the native API is much quicker and, therefore, we would prefer to use it.

Is there a good reason why Glassfish defaults to setting NativeXA to false?
Is there a good reason why I should not either a) set it to true or b) remove the setting completely?

Any suggestions or insights welcome :-)

Chris

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Definition of Oracle XA datasources

Paul Peters
In reply to this post by Chris Selwyn
Hmmm yeah, you're onto something there.
i've avoided not using JAVA_XA due to issues with 10g, and
there was no need to dive deeper as performance was more
than adequate. IIRC there were some JavaSE version
dependencies as well, but switching on JAVA_XA instead of
any native functioning worked good enough.
I'd like to see some comparative figures on the differences
though.

Would you need the OCI driver for Type 2 JDBC which calls an
underlying C API ? Not sure why Glassfish defaults to
disabling it, but maybe that has been for demo purposes
which are low on the configuration effort (apparently 45% of
J2EE App server issues in production environments are
related to configuration errors).

Well, maybe someone who worked on it can tell, or maybe it
was a correction 5 years ago and became a habit.

Take care
Paul


----- Original Message Follows -----
From: Chris Selwyn

>
> As far as I can tell the NativeXA flag only controls how
> XA transactions  are communicated to the database... It
> does not control whether or not  XA is being used.
> JAVA_XA is not needed since Oracle 10g because the thin
> JDBC driver can  use the native XA API.
> But then the default Glassfish entry stops the JDBC driver
> from using  the native API... Doesn't make sense to me.
>
> Chris
>
> On 26/01/2010 15:12, Paul Peters wrote:
> >
> > Hi Chris,
> >
> > As far as I know this has been so for quite some years..
> > and it has to  do with local transactions being a lot
> > quicker and easier to use than  global transactions. XA
> > isn't so common place when having quite some  choice
> such as pessimistic locking, etcetera. For the same reason
> > JAVA_XA isn't installed by default.
> >
> > NativeXA... haven't fiddled around with that one yet,
> > but I wonder,  when the JVM has heated up, if it makes
> so much of a difference.. >
> > Take care
> >
> > Paul
> >
> > *From:* Chris Selwyn
> >
> > I have just got to the bottom of why my customer's XA
> > datasources have  not been working...
> >
> > It is a result of two things:-
> >
> >     * They had not installed the JAVA_XA package in
> >       Oracle 11g
> >    * By default Oracle XA datasources
> >       explicitly set NativeXA=false
> > I realise that getting the customer to install the
> > JAVA_XA package  would solve the problem but according
> > to the Oracle docs the native  API is much quicker and,
> therefore, we would prefer to use it. >
> > Is there a good reason why Glassfish defaults to setting
> > NativeXA to  false?
> > Is there a good reason why I should not either a) set it
> > to true or b)  remove the setting completely?
> >
> > Any suggestions or insights welcome :-)
> >
> > Chris
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Definition of Oracle XA datasources

Chris Selwyn
The NativeXA API does not need the OCI driver.

Chris

On 26/01/2010 21:24, [hidden email] wrote:

> Hmmm yeah, you're onto something there.
> i've avoided not using JAVA_XA due to issues with 10g, and
> there was no need to dive deeper as performance was more
> than adequate. IIRC there were some JavaSE version
> dependencies as well, but switching on JAVA_XA instead of
> any native functioning worked good enough.
> I'd like to see some comparative figures on the differences
> though.
>
> Would you need the OCI driver for Type 2 JDBC which calls an
> underlying C API ? Not sure why Glassfish defaults to
> disabling it, but maybe that has been for demo purposes
> which are low on the configuration effort (apparently 45% of
> J2EE App server issues in production environments are
> related to configuration errors).
>
> Well, maybe someone who worked on it can tell, or maybe it
> was a correction 5 years ago and became a habit.
>
> Take care
> Paul
>
>
> ----- Original Message Follows -----
> From: Chris Selwyn
>  
>> As far as I can tell the NativeXA flag only controls how
>> XA transactions  are communicated to the database... It
>> does not control whether or not  XA is being used.
>> JAVA_XA is not needed since Oracle 10g because the thin
>> JDBC driver can  use the native XA API.
>> But then the default Glassfish entry stops the JDBC driver
>> from using  the native API... Doesn't make sense to me.
>>
>> Chris
>>
>> On 26/01/2010 15:12, Paul Peters wrote:
>>    
>>> Hi Chris,
>>>
>>> As far as I know this has been so for quite some years..
>>> and it has to  do with local transactions being a lot
>>> quicker and easier to use than  global transactions. XA
>>> isn't so common place when having quite some  choice
>>>      
>> such as pessimistic locking, etcetera. For the same reason
>>    
>>> JAVA_XA isn't installed by default.
>>>
>>> NativeXA... haven't fiddled around with that one yet,
>>> but I wonder,  when the JVM has heated up, if it makes
>>>      
>> so much of a difference.. >
>>    
>>> Take care
>>>
>>> Paul
>>>
>>> *From:* Chris Selwyn
>>>
>>> I have just got to the bottom of why my customer's XA
>>> datasources have  not been working...
>>>
>>> It is a result of two things:-
>>>
>>>     * They had not installed the JAVA_XA package in
>>>       Oracle 11g
>>>    * By default Oracle XA datasources
>>>       explicitly set NativeXA=false
>>> I realise that getting the customer to install the
>>> JAVA_XA package  would solve the problem but according
>>> to the Oracle docs the native  API is much quicker and,
>>>      
>> therefore, we would prefer to use it. >
>>    
>>> Is there a good reason why Glassfish defaults to setting
>>> NativeXA to  false?
>>> Is there a good reason why I should not either a) set it
>>> to true or b)  remove the setting completely?
>>>
>>> Any suggestions or insights welcome :-)
>>>
>>> Chris
>>>
>>>      
>>    
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Definition of Oracle XA datasources

Paul Peters
So, if it's a type 4 JDBC driver, why would it need the NativeXA API in the
first place ?
Type 4 is a complete java implementation without the need for any native
code.


Odd though, as the documentation says :
" Allows an OracleXADataSource using the Native XA feature with the OCI
driver, to access Oracle pre-8.1.6 databases and later. If the nativeXA
property is enabled, be sure to set the tnsEntry property as well. This
property is only for OracleXADatasource.
This DataSource property defaults to false."

There are also references to things like "OCI HeteroRM XA", but again it's
OCI, thus type 2.
Anyway, given the remark above that NativeXA defaults to false, then setting
it explicitly is a bit overkill...

Take care
Paul


-----Original Message-----
From: Chris Selwyn

The NativeXA API does not need the OCI driver.

Chris

On 26/01/2010 21:24, [hidden email] wrote:

> Hmmm yeah, you're onto something there.
> i've avoided not using JAVA_XA due to issues with 10g, and
> there was no need to dive deeper as performance was more
> than adequate. IIRC there were some JavaSE version
> dependencies as well, but switching on JAVA_XA instead of
> any native functioning worked good enough.
> I'd like to see some comparative figures on the differences
> though.
>
> Would you need the OCI driver for Type 2 JDBC which calls an
> underlying C API ? Not sure why Glassfish defaults to
> disabling it, but maybe that has been for demo purposes
> which are low on the configuration effort (apparently 45% of
> J2EE App server issues in production environments are
> related to configuration errors).
>
> Well, maybe someone who worked on it can tell, or maybe it
> was a correction 5 years ago and became a habit.
>
> Take care
> Paul
>
>
> ----- Original Message Follows -----
> From: Chris Selwyn
>  
>> As far as I can tell the NativeXA flag only controls how
>> XA transactions  are communicated to the database... It
>> does not control whether or not  XA is being used.
>> JAVA_XA is not needed since Oracle 10g because the thin
>> JDBC driver can  use the native XA API.
>> But then the default Glassfish entry stops the JDBC driver
>> from using  the native API... Doesn't make sense to me.
>>
>> Chris
>>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...