Roman Rokytskyy wrote:

>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.
>
>

It provides access to a capability of the underlying database engine
that is useful to applications. It is like any extension consistent
with a standard -- invisible unless you use it. On it's own merits, it
is much more resource efficient than two independent connections, which
is the standard JDBC workaround.

>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.
>
>

There is no reason why a cloned connection, when closed, need go back
into a connection pool. It could go away completely or hang off it's
parent connection for reuser.

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

There is no need to a connection pool to handle it at all.

>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.
>
>
>

I don't see the problem at all. The behavior of the cloned connection
would be the same as the parent connection. Clearly you couldn't clone
a connection before the attachment is complete, and a failure after
attachment is an error to be reported.



[Non-text portions of this message have been removed]