Aha! Suddenly everything becomes clear!
On Mon, 22 May 2000, Rickard [iso-8859-1] �berg wrote:
> Hold on!!! You have used a *connection* (a pipe, something to send stuff
> through, but *not* a data storage) to execute queries. All that data has
> been sent to the database. The data is *not* tied to the connection as
> such, it is tied to the *tx*. The connection is just a pipe we use to
> shuffle our stuff through.
I wasn't aware you could distinguish between a connection and a
transaction in JDBC. But perhaps this is what you meant when you talked
about 2.0 drivers. So you're saying that with a "2.0" driver, the DBMS
vendor implements XAResources and XAConnections within their driver, so
we don't deal directly with the connections or transactions - they handle
it all for us. Magical!
I went back and looked at the Oracle drivers, and discovered that
that latest drivers do indeed support this - they provide an XADataSource.
That sures saves a bundle of work! NOW we're on the same page!
However, this simply raises a new and different set of questions.
Sigh.
1) How many drivers implement this? I suspect not too many, but I'd love
ot be surprised.
2) Unfortunately, the DataSource interface does not include any methods
for configuring the DataSource. That is, there's no standard way to
specify the server, port, instance/database, URL, etc. The spec suggests
that the implementation be beany (get/set for all properties), but only
"suggests" the properties. So how do we allow configuration? I suppose
we can take a property list and try to invoke an appropriate setXXX method
for each proparty via reflection, and error out if we can't find an
appropriate method...
3) What do we do with drivers that don't implement this? I think we may
have the same intention here, which is to create a wrapper for 1.0 drivers
where we implement all the XA stuff and prevent bad things from happening.
Aaron
