Subject | Re: [Firebird-Java] Various transactions for one connection |
---|---|
Author | Roman Rokytskyy |
Post date | 2004-10-19T15:04:54Z |
Jim,
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?
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
> It provides access to a capability of the underlying database engineOk, I buy this argument.
> 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 aSee below.
>> 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 connectionsMy experience (that can be confirmed with AS3AP tests) shows that connection
>> correctly.
> There is no need to a connection pool to handle it at all.
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 clonedDo you mean something like "auxilary connection", lifetime of which is not
> 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.
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