Hi Kevin, one more thing..
We use Websphere Datasources that use these drivers.. 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 <[email protected]> > 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 <[email protected]> >> 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-tp2722877p2728403.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
