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.
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"
I tried to move all DDL operations to separate XA data
sources. This didn't seem like the best idea and it didn't
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).
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
hope this helps
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
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
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
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
Will executing DDL on my "DDL Datasource"
cause problems if it is backed by an XA