On 8/17/12 5:42 PM, [email protected] wrote:
Knut Anders Hatlen wrote:
What I meant was that existing applications written against Derby will
already have been coded so that they explicitly commit or abort the
transaction before they close the connection. This means they are not
likely to be affected by a change in how we handle closing of active
transactions.
Rick Hillegas<[email protected]> writes:
I remain concerned about backward compatibility and would object to
option (3).
If Knut's analysis holds (I think it does), how do you see backward
compatibility being a problem, Rick? It seems to me this could
potentially trip up developers used to the old Derby behavior,
Hi Dag,
I don't understand the question. Backward compatibility is exactly what
you just described: a change in behavior for applications which are used
to the old behavior.
but not
apps developed against Derby with the existing behavior. I'd say that is
an accentable price to pay in this case, given proper release note heads
up.
This is the scenario which would be handled by adding a new knob.
Thanks,
-Rick
Dag
