Return-Path: Delivered-To: apmail-geronimo-user-archive@www.apache.org Received: (qmail 10927 invoked from network); 12 Dec 2007 01:29:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Dec 2007 01:29:42 -0000 Received: (qmail 27075 invoked by uid 500); 12 Dec 2007 01:29:29 -0000 Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org Received: (qmail 27051 invoked by uid 500); 12 Dec 2007 01:29:29 -0000 Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: user@geronimo.apache.org List-Id: Delivered-To: mailing list user@geronimo.apache.org Received: (qmail 27039 invoked by uid 99); 12 Dec 2007 01:29:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Dec 2007 17:29:29 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [66.219.42.203] (HELO 21ctexg01.21technologies.com) (66.219.42.203) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Dec 2007 01:29:30 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83C5E.646118F2" Subject: RE: Usage of TranQL Date: Tue, 11 Dec 2007 19:29:09 -0600 Message-ID: <54D41E91F26CF6488C7088C89D9160F868BDFF@21ctexg01.21technologies.com> In-Reply-To: <9B28FE17-14C0-4605-A5FB-AE27F0077833@yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Usage of TranQL Thread-Index: Acg8Oh5TfLfcKnazT3+NpmmdcjoC4QAIdR+A References: <54D41E91F26CF6488C7088C89D9160F868BD7D@21ctexg01.21technologies.com> <9B28FE17-14C0-4605-A5FB-AE27F0077833@yahoo.com> From: "Jimmy Wan" To: X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C83C5E.646118F2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, thanks for the response. =20 In our particular scenario, we have a handful of statically defined data sources (configured/viewable via Geronimo), but we also have a potentially large number of dynamic data sources that we're trying to create on the fly. It is the configuration of these dynamic data sources that is proving somewhat tricky. Up till now, we've been using some combination of custom code, TranQL connectors, and vendor provided XA DataSources. From the initial conversations on this list (years ago now), the consensus seemed to be that the creation of dynamic data sources would not really be possible without writing a GBean and jumping through some hoops. Having created a similar system in the past where we just created/bound the data sources directly into JNDI, that seemed like a lot of work for minimal benefit. =20 Original Code: We had been using JTA everywhere via BMT until we started running into an issue with DDL apparently screwing up DML. So I decided to try and separate out the usage of DDL/DML to separate data sources. Most of the transactions are "pretty small". Everything is close to a transaction-per-request or smaller. We have no "long-running" transactions. =20 First Change: I tried to move all DDL operations to separate XA data sources. This didn't seem like the best idea and it didn't work. =20 Second Change: JTA in code with BMT for DML. DDL will be handled in separate local JDBC data sources that should have no transaction management. This is not working yet, but it seems like this would be the best way to avoid complications arising from the execution of DDL. As an aside, it is possible to interact with the DDL and DML databases. The DDL/DML do not need to be kept within a single transaction boundary. =20 In all cases, we are using custom JCA code. Originally, we couldn't find the Geronimo JCA implementation. Now that I've seen it, it looks as though it would be hard to programmatically add/remove data sources. The Geronimo JCA implementation looks too heavyweight for what I'd like to do. (just provide some connection info and be done). =20 ________________________________ From: David Jencks [mailto:david_jencks@yahoo.com]=20 Sent: Tuesday, December 11, 2007 15:10 To: user@geronimo.apache.org Subject: Re: Usage of TranQL The tranql lists are not exactly dead but there is very little development going on. Since you want to know how to use the connectors inside geronimo this seems like a better list. You have left out a lot of details about what you are trying to do, especially about transactions and how you are controlling them (JTA, local, etc) and how much work you want to get into each transaction.=20 Generally DDL doesn't mix well with transactions. I suggest you use a no-tx datasource such as the one we provide in geronimo 2.x for the DDL. If you are not using JTA but rather local transactions then it would be appropriate to use this datasource for the DML as well. If you are using JTA transactions then something like the system-datasource would be more appropriate. hope this helps david jencks On Dec 11, 2007, at 10:34 AM, Jimmy Wan wrote: Does anyone know if there is a new TranQL mailing list? The one on codehaus appears to be dead, form the archives I found. It seems like Tranql development was adopted by the Geronimo team, so I'll fire away here. =20 I'm having some trouble with my application which needs to perform plain SQL as well as execute some DDL. Right now, we are incorrectly mixing the SQL/DDL which inadvertently commits things and changes the autocommit values in ways that we don't want. I'd like to completely separate my DDL statements by putting them into their own entirely separate datasource but I'm unsure how to do this. =20 As I understand it, Tranql lets you do things such as have non-XA resources participate in XA transactions. However, what if I have things that need to happen outside the boundary of an XA transaction (such as DDL)? =20 Using Derby as an example: There are two managed connection factories as part of the tranql-connector-derby package: ClientLocalMCF backed by a non-XA driver and ClientXAMCF backed by an XA driver. =20 Do I need to create a local data source backed by a ClientLocalMCF as well as an XA data source backed by ClientXAMCF? =09 Would it be OK to create two data source that are both backed by the XA driver using ClientXAMCF as long as I keep my DDL operations separate from the other SQL statements? Will executing DDL on my "DDL Datasource" cause problems if it is backed by an XA DataSource? ------_=_NextPart_001_01C83C5E.646118F2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
David, thanks for the = response.
 
In our particular scenario, we have a handful = of statically=20 defined data sources (configured/viewable via Geronimo), but we also = have a=20 potentially large number of dynamic data sources that we're trying to = create on=20 the fly. It is the configuration of these dynamic data sources that is = proving=20 somewhat tricky. Up till now, we've been using some combination of = custom code,=20 TranQL connectors, and vendor provided XA DataSources. From the initial=20 conversations on this list (years ago now), the consensus seemed to be = that the=20 creation of dynamic data sources would not really be possible without = writing a=20 GBean and jumping through some hoops. Having created a similar system in = the=20 past where we just created/bound the data sources directly into JNDI, = that=20 seemed like a lot of work for minimal benefit.
 
Original Code:
We had been using JTA everywhere via BMT until = we started=20 running into an issue with DDL apparently screwing up DML. So I decided = to try=20 and separate out the usage of DDL/DML to separate data sources. Most of = the=20 transactions are "pretty small". Everything is close to a=20 transaction-per-request or smaller. We have no "long-running"=20 transactions.
 
First Change:
I tried to move all DDL operations to separate = XA data=20 sources. This didn't seem like the best idea and it didn't=20 work.
 
Second Change:
JTA in code with BMT for DML. DDL will be = handled in=20 separate local JDBC data sources that should have no transaction = management.=20 This is not working yet, but it seems like this would be the best way to = avoid=20 complications arising from the execution of DDL. As an aside, it is = possible to=20 interact with the DDL and DML databases. The DDL/DML do not need to be = kept=20 within a single transaction boundary.
 
In all cases, we are using custom JCA code. = Originally, we=20 couldn't find the Geronimo JCA implementation. Now that I've seen it, it = looks=20 as though it would be hard to programmatically add/remove data sources. = The=20 Geronimo JCA implementation looks too heavyweight for what I'd like to = do. (just=20 provide some connection info and be done).
 
From: David Jencks=20 [mailto:david_jencks@yahoo.com]
Sent: Tuesday, December 11, = 2007=20 15:10
To: user@geronimo.apache.org
Subject: Re: = Usage of=20 TranQL

The tranql lists are not exactly dead but there is very little = development=20 going on.  Since you want to know how to use the connectors inside = geronimo=20 this seems like a better list.

You  have left out a = lot of=20 details about what you are trying to do, especially about transactions = and how=20 you are controlling them (JTA, local, etc) and how much work you want to = get=20 into each transaction.

Generally DDL doesn't mix well with transactions.  I suggest = you use a=20 no-tx datasource such as the one we provide in geronimo 2.x for the = DDL. =20 If you are not using JTA but rather local transactions then it would be=20 appropriate to use this datasource for the DML as well.  If you are = using=20 JTA transactions then something like the system-datasource would be more = appropriate.

hope this helps
david jencks

On Dec 11, 2007, at 10:34 AM, Jimmy Wan wrote:
Does = anyone know=20 if there is a new TranQL mailing list? The one on codehaus appears to = be dead,=20 form the archives I found. It seems like Tranql development was = adopted by the=20 Geronimo team, so I'll fire away here.
 
I'm = having some=20 trouble with my application which needs to perform plain SQL as well = as=20 execute some DDL. Right now, we are incorrectly mixing the SQL/DDL = which=20 inadvertently commits things and changes the autocommit values in ways = that we=20 don't want. I'd like to completely separate my DDL statements by = putting them=20 into their own entirely separate datasource but I'm unsure how to do=20 this.
 
As I = understand=20 it, Tranql lets you do things such as have non-XA resources = participate in XA=20 transactions. However, what if I have things that need to happen = outside the=20 boundary of an XA transaction (such as DDL)?
 
Using Derby as an=20 example:
There are two=20 managed connection factories as part of the tranql-connector-derby = package:=20 ClientLocalMCF backed by a non-XA driver and ClientXAMCF backed by an = XA=20 driver.
 
Do I = need to=20 create a local data source backed by a ClientLocalMCF as well as an XA = data=20 source backed by ClientXAMCF?
Would it be OK to=20 create two data source that are both backed by the XA driver using = ClientXAMCF=20 as long as I keep my DDL operations separate from the other SQL=20 statements?
Will executing DDL on my "DDL = Datasource"=20 cause problems if it is backed by an XA=20 = DataSource?

= ------_=_NextPart_001_01C83C5E.646118F2--