2nd try from a hopefully more subscribed address
Begin forwarded message:

> From: David Jencks <djencks@...>
> Date: October 19, 2004 9:15:22 AM PDT
> To: Firebird-Java@yahoogroups.com
> Subject: Re: [Firebird-Java] Various transactions for one connection
>
>
> On Oct 19, 2004, at 7:11 AM, Jim Starkey wrote:
>
>> 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.
>
> Actually the way to handle this situation in java is using JTA/XA.
> Delist the XAResource associated with the managed connection from the
> first tx, suspend the first tx, resume/create the second tx, enlist
> the XAResource with the second tx, and reverse to get back to the
> first tx.
>
> This is done automatically for you in an ejb container when you make a
> "RequiresNew" call. However, in this case, you have to do all the
> work on the "inner" transaction in one call: you can't switch back
> and forth between transactions.
>>
>> >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.
>
> Don't confuse connection handles visible to the user with managed
> connections that are pooled.
>>
>> >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.
>
> I don't see how this could turn into a popular feature and since it
> has nothing to do with any spec-described behavior and since there is
> a (albeit inconvenient) way to get the same behavior using existing
> functionality I'm not in favor of it.
>
> If the wire protocol was asynchronous and my oft-repeated request to
> untie transactions from connections were to be implemented I'd be
> strongly in favor of sharing a limited number of physical connections
> among a much larger set of connection handles.
>
> david jencks
>>
>>
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>>
>> Yahoo! Groups Sponsor
>>
>> ADVERTISEMENT
>> <f2_free2_300x250_def_0904.gif>
>> <l.gif>
>>
>> Yahoo! Groups Links
>>
>> • To visit your group on the web, go to:
>> http://groups.yahoo.com/group/Firebird-Java/
>>  
>> • To unsubscribe from this group, send an email to:
>> Firebird-Java-unsubscribe@yahoogroups.com
>>  
>> • Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>> Service.
>>
>>