I'll respond in more detail later.... but I have a couple questions
1. What are the xa recovery requirements for these "dynamically
defined" datasources?
2. do these dynamic datasources need connection pooling?
3. what exactly happens if you try to do ddl on a connection from an
xa-enabled datasource while not in a jta transaction? I would expect
that if there is no xa tx, then you could do DDL and nothing would
break. I would be surprised if DDL in a jta tx worked :-)
I think it would not be that hard to set up geronimo managed pools
for xa datasources, but the getting recovery to work may be tricky...
you need to remember all the resource managers in some way. We are
doing it through the gbeans for the connection managers, but another
way might be plausible.
thanks
david jencks
On Dec 11, 2007, at 5:29 PM, Jimmy Wan wrote:
David, thanks for the response.
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.
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.
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.
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.
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).
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 11, 2007 15:10
To: [email protected]
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.
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.
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.
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)?
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.
Do I need to create a local data source backed by a ClientLocalMCF
as well as an XA data source backed by ClientXAMCF?
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?
