Jim,

> Something you might consider adding to the Jaybird Connection class
> is a cloneConnection() method that would multiplex on the same
> database attachment while giving a separate transaction. The
> implementation should be simple, though it might slightly complicate
> the object accounting.

What's the point of this change?

The drawbacks I see are:

1. This is not JDBC compatible, no application that conforms JDBC would be
able to use this code.

2. It seems to be incompatible with JCA, since it allows to use a physical
connection even the corresponding managed connection would be returned to
the pool.

3. No connection pool would be able to handle such connections correctly.

4. (not really an excuse and is related to issue 2, but would require a lot
of changes). Current implementation has a concept of reopening physical
connection if some errors (list is hardcoded) happens before the new
transaction is started (some kind of transparent failover). This code is
perfectly JDBC and JCA conformant, but if we introduce the connection
cloning, it can happen that one JDBC connection is working, another tries to
start the transaction, gets an error and reopens connection. The first
connection would be really surprised by this behavior.

Your suggestion would make sense if I could use a transaction handle with
different connection objects. Then we could have something like a connection
pool of 5 socket connections and multiplex them for 20 transactions.
However, since this is not available, I find this change confusing and error
prone.

Roman