Subject Re: [Firebird-Java] Various transactions for one connection
Author Roman Rokytskyy
Jim,

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

Ok, I buy this argument.

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

See below.

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

My experience (that can be confirmed with AS3AP tests) shows that connection
pooling brings much less than prepared statement pooling. Prepared statement
pooling itself does not bring a lot when connection pooling is not enabled
(i.e. caching between getConnection/close is useful only if people execute
multiple prepared statements before returning connection to the pool).

So, the only thing that we solve, is one allocated connection. Is it really
so important?

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

Do you mean something like "auxilary connection", lifetime of which is not
greater than the lifetime of the "main" connection (also in terms of pool)?
It would be relatively easy (compared to the next case) to implement. Does
such case make sense?

Or you mean completely independent connection? This case would require
substantial changes in JCA code, and, frankly speaking, I cannot provide a
correct JCA implementation in this case. We have to ask David Jencks whether
this is possible at all.

Roman