Jeroen wrote:
> Granted, that's probably going to force the issue. I do wonder
though:
> one of the arguments in favour of the current semantics is that the
> problems can be worked around using nested transactions. Then what
were
> people doing before nested transactions, in Tom's scenario where the
> programmer doesn't know where transactions begin?
The trick is that with the current semantics, you don't have to watch
transaction activity, just the prepare statements. You know if and when
(from the client/driver's point of view) a prepared statement exists
because you created it and don't have to be concerned about the
lifetime.
If you guys change the lifetime, it becomes difficult or impossible to
set a flag on the client which guarantees prepared statement existence.
This means I have to wrap the statement execution with a subtransaction
or run the risk of bouncing a current transaction. Currently in the
applications I write 70% of all I/O goes through prepared
statements...the reason to do this was to reduce statement turnaround
latency, which is the main driving performance factor in COBOL
applications.
I would be fine with changing the lifetime if an EXECUTE failure did not
abort the current transaction. Then I could simply watch the return
code of the statement execution and prepare the statement on
demand...from my point of view, this would actually be the most elegant
scenario.
Merlin
