You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Chandra Sarath <ct...@yahoo.com> on 2009/05/01 18:05:21 UTC
Re: Open JPA recommended driver for DB2
Hi Kevin,
Could you please let me know if we consider the performance only, which
drivers have better performance XA or non XA?
Thanks,
Chandra
Chandra Sarath wrote:
>
> Hi Kevin,
>
> Yes. We donot experience the problem if we use XA drivers. But we have
> tested that problem for only updates but not inserts. Remeber that (see
> Thread 1) non-XA drivers timed out fine for inserts and did not time out
> for updates. For XA drivers we tested only updates. We couldn't test
> inserts as we had different problems. Before we change it to XA we wanted
> to know there are no new issues related to XA drivers. I would like to
> know if we can fix the problems with non-xa drivers itself..
>
> Thanks,
> Chandra
>
>
>
> Kevin Sutter wrote:
>>
>> Hi Chandra,
>> More interesting data... :-) So, you are saying that if you use the
>> JDBC
>> XA driver with DB2 and WAS v6.1 with the EJB3 Feature Pack, then you do
>> not
>> experience the problem we've been discussing in the other thread [1]?
>> Everything else is the same, just a different JDBC driver? And, this is
>> configured as part of your WebSphere Datasource?
>>
>> If this is your only variable, then moving to the XA driver should inject
>> minimal risk. In theory, this XA driver knows how to participate in an
>> XA
>> transaction. (And, Paul is right, XA is a big subject.) If this
>> resolves
>> your other issue, I wouldn't hesitate on using the XA driver over the
>> non-XA
>> driver. But, then will we ever to the bottom of your original posting?
>> :-)
>>
>> Kevin
>>
>> [1]
>> http://n2.nabble.com/OpenJpa%2C-and-DB2-shared-lock-td2675084.html#a2727497
>>
>> On Mon, Apr 27, 2009 at 12:03 PM, Chandra Sarath <ct...@yahoo.com>
>> wrote:
>>
>>>
>>> Hi Kevin,
>>>
>>> What exactly is multiple resources mean? We are using Websphere 6.1
>>> Feature
>>> pack 3.
>>>
>>> One of the reason why we are thinking about using XA driver is if we
>>> have a
>>> database timeout of 30 sec, if we use non-xa drivers the database
>>> transaction from OpenJpa tries unlimited before we force it to exit.
>>> Whereas
>>> if we use XA drivers, the database transaction exits at the 30 sec
>>> timeouts.
>>> But we are worried about any other issues XA drivers cause and we donot
>>> have
>>> much time to research on this. We have been using non-xa drivers.
>>>
>>> Thanks,
>>> Chandra
>>>
>>>
>>>
>>>
>>> Kevin Sutter wrote:
>>> >
>>> > Personally, if your processing does not require the use of XA, then I
>>> > would
>>> > stick with non-XA. XA is used when you have multiple resources
>>> > participating in a transaction. So, besides the driver itself, there
>>> is
>>> > also the transaction processing within the app server that may have
>>> > additional overhead. In the case of WebSphere, that overhead is kept
>>> to
>>> a
>>> > minimum until a second resource is introduced into the mix. So, if
>>> you
>>> > only
>>> > deal with a single resource within a given transaction, then the use
>>> of
>>> XA
>>> > shouldn't hurt too much. But, along those same lines, if you only
>>> deal
>>> > with
>>> > a single resource, then why even introduce the possibility?
>>> >
>>> > This question is really between your application server and the
>>> database.
>>> > OpenJPA really doesn't come into play since we just attach ourselves
>>> to
>>> > the
>>> > current transaction context. It's the interaction between the
>>> transaction
>>> > (app server) and the database that should affect your decision.
>>> >
>>> > Kevin
>>> >
>>> > On Mon, Apr 27, 2009 at 2:48 AM, Chandra Sarath <ct...@yahoo.com>
>>> wrote:
>>> >
>>> >>
>>> >> Hi,
>>> >>
>>> >> We are using DB2 LUW 9.1 fixpack 4 as our Database. Could you please
>>> >> recommend which driver (XA or non XA) is suitable for openJPA 1.2.0
>>> and
>>> >> DB2.
>>> >> We use transactions a lot while doing inserts/updates/retrive
>>> >> operations.
>>> >>
>>> >> Thanks,
>>> >> Chandra
>>> >>
>>> >>
>>> >> --
>>> >> View this message in context:
>>> >>
>>> http://n2.nabble.com/Open-JPA-recommended-driver-for-DB2-tp2722877p2722877.html
>>> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://n2.nabble.com/Open-JPA-recommended-driver-for-DB2-tp2722877p2727257.html
>>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
>
--
View this message in context: http://n2.nabble.com/Open-JPA-recommended-driver-for-DB2-tp2722877p2753969.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Open JPA recommended driver for DB2
Posted by Kevin Sutter <kw...@gmail.com>.
Since it doesn't sound like you are really using XA Transactional
capabilities, then there should be no performance impact to using the XA
driver. From my perspective, the performance concerns would come in with
using the XA Transactional capilities from an app server perspective. And,
the use of multiple resources that would force the XA transaction. Since
that doesn't seem to be the case, using the XA driver by itself should not
have an impact.
That's my personal opinion. :-)
Good luck,
Kevin
On Fri, May 1, 2009 at 11:05 AM, Chandra Sarath <ct...@yahoo.com> wrote:
>
> Hi Kevin,
>
> Could you please let me know if we consider the performance only, which
> drivers have better performance XA or non XA?
>
> Thanks,
> Chandra
>
>
>
>
> Chandra Sarath wrote:
> >
> > Hi Kevin,
> >
> > Yes. We donot experience the problem if we use XA drivers. But we have
> > tested that problem for only updates but not inserts. Remeber that (see
> > Thread 1) non-XA drivers timed out fine for inserts and did not time out
> > for updates. For XA drivers we tested only updates. We couldn't test
> > inserts as we had different problems. Before we change it to XA we wanted
> > to know there are no new issues related to XA drivers. I would like to
> > know if we can fix the problems with non-xa drivers itself..
> >
> > Thanks,
> > Chandra
> >
> >
> >
> > Kevin Sutter wrote:
> >>
> >> Hi Chandra,
> >> More interesting data... :-) So, you are saying that if you use the
> >> JDBC
> >> XA driver with DB2 and WAS v6.1 with the EJB3 Feature Pack, then you do
> >> not
> >> experience the problem we've been discussing in the other thread [1]?
> >> Everything else is the same, just a different JDBC driver? And, this is
> >> configured as part of your WebSphere Datasource?
> >>
> >> If this is your only variable, then moving to the XA driver should
> inject
> >> minimal risk. In theory, this XA driver knows how to participate in an
> >> XA
> >> transaction. (And, Paul is right, XA is a big subject.) If this
> >> resolves
> >> your other issue, I wouldn't hesitate on using the XA driver over the
> >> non-XA
> >> driver. But, then will we ever to the bottom of your original posting?
> >> :-)
> >>
> >> Kevin
> >>
> >> [1]
> >>
> http://n2.nabble.com/OpenJpa%2C-and-DB2-shared-lock-td2675084.html#a2727497
> >>
> >> On Mon, Apr 27, 2009 at 12:03 PM, Chandra Sarath <ct...@yahoo.com>
> >> wrote:
> >>
> >>>
> >>> Hi Kevin,
> >>>
> >>> What exactly is multiple resources mean? We are using Websphere 6.1
> >>> Feature
> >>> pack 3.
> >>>
> >>> One of the reason why we are thinking about using XA driver is if we
> >>> have a
> >>> database timeout of 30 sec, if we use non-xa drivers the database
> >>> transaction from OpenJpa tries unlimited before we force it to exit.
> >>> Whereas
> >>> if we use XA drivers, the database transaction exits at the 30 sec
> >>> timeouts.
> >>> But we are worried about any other issues XA drivers cause and we donot
> >>> have
> >>> much time to research on this. We have been using non-xa drivers.
> >>>
> >>> Thanks,
> >>> Chandra
> >>>
> >>>
> >>>
> >>>
> >>> Kevin Sutter wrote:
> >>> >
> >>> > Personally, if your processing does not require the use of XA, then I
> >>> > would
> >>> > stick with non-XA. XA is used when you have multiple resources
> >>> > participating in a transaction. So, besides the driver itself, there
> >>> is
> >>> > also the transaction processing within the app server that may have
> >>> > additional overhead. In the case of WebSphere, that overhead is kept
> >>> to
> >>> a
> >>> > minimum until a second resource is introduced into the mix. So, if
> >>> you
> >>> > only
> >>> > deal with a single resource within a given transaction, then the use
> >>> of
> >>> XA
> >>> > shouldn't hurt too much. But, along those same lines, if you only
> >>> deal
> >>> > with
> >>> > a single resource, then why even introduce the possibility?
> >>> >
> >>> > This question is really between your application server and the
> >>> database.
> >>> > OpenJPA really doesn't come into play since we just attach ourselves
> >>> to
> >>> > the
> >>> > current transaction context. It's the interaction between the
> >>> transaction
> >>> > (app server) and the database that should affect your decision.
> >>> >
> >>> > Kevin
> >>> >
> >>> > On Mon, Apr 27, 2009 at 2:48 AM, Chandra Sarath <ct...@yahoo.com>
> >>> wrote:
> >>> >
> >>> >>
> >>> >> Hi,
> >>> >>
> >>> >> We are using DB2 LUW 9.1 fixpack 4 as our Database. Could you
> please
> >>> >> recommend which driver (XA or non XA) is suitable for openJPA 1.2.0
> >>> and
> >>> >> DB2.
> >>> >> We use transactions a lot while doing inserts/updates/retrive
> >>> >> operations.
> >>> >>
> >>> >> Thanks,
> >>> >> Chandra
> >>> >>
> >>> >>
> >>> >> --
> >>> >> View this message in context:
> >>> >>
> >>>
> http://n2.nabble.com/Open-JPA-recommended-driver-for-DB2-tp2722877p2722877.html
> >>> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>>
> >>> --
> >>> View this message in context:
> >>>
> http://n2.nabble.com/Open-JPA-recommended-driver-for-DB2-tp2722877p2727257.html
> >>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >>>
> >>>
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Open-JPA-recommended-driver-for-DB2-tp2722877p2753969.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>