On 8/17/12 5:42 PM, dag.wanvik@oracle.com 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<rick.hillegas@oracle.com> 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
>
|