Blas Rodriguez Somoza wrote:

>
> I think we need a real autocommit mode, even as a new "execute_auto"
> protocol request with start, execute and commit implied.

I'd like to suggest that we move this discussion to the architecture
list. We'll get a good blast from the BBW on the merits of autocommit,
but I would like a general discussion around the implications of a new
variant of execute-immediate that starts and ends its own transaction.
For instance, what happens if there's already a transaction active?
Would it make more sense to have a transaction start that sets an
auto-commit mode and continues in that mode until that "transaction"
finishes?

> Whether the performance of FB in explicit transaction mode is very
> good, when using autocommit the times are really bad
>
> The following are some performance numbers for FB on Win32 (with
> forced writes off) from the Java POV
>
> times in % of FB times.
>
> Autocommit mode
> Mysql/InnoDB 20% of FB
> SAPDB 150% of FB
> Transaction mode (huge transactions)
> Mysql/InnoDB 110% of FB
> SAPDB 340% of FB
>
> Even if those numbers are biased by the jdbc driver and database
> arquitecture, I think it is clear that FB needs an autocommit mode.
>
> Now in autocommit mode, the remote server needs to receive and process
> 3 times more requests than needed (start transaction, execute, commit)
> and this must have some influence on performance.
>
> Of course the performance depends on usage, but what will happen in an
> scenario with high number of clients and one sql command transactions?.
>
> Regards
> Blas Rodriguez Somoza
>