Re: [Dbi-interbase-devel] Progress

[Mark D. A. <md...@di...>]

(resending this rant for the record, now that my clock is fixed so it doesn't look
like i'm a week behind).

----- Original Message ----- 
From: Mark D. Anderson <md...@di...>
To: <dbi...@li...>
Sent: Monday, August 14, 2000 8:32 PM
Subject: Re: [Dbi-interbase-devel] Progress

> * starting a transaction (automatic or not) is more robust, now it
> reuses an active transaction handle, instead of overridding it with a new one,
> leaving the previous one "immortal" (because the previous transaction handle is
> no longer kept!)

however, there is still zero support in this version for any kind of control
over the transactions created -- something i consider important for both
the case of AutoCommit on or off.

in the AutoCommit=on case, the 3rd argument to your ib_start_transaction is always NULL,
so there is no way to provide it.

For example, at connect time, I'd like to provide 
   Dialect => 3,
   Default_Transaction_Parameters => {Access => 'WRITE', Isolation => 'CONCURRENCY', Resolution => 'WAIT'}

in the AutoCommit=off case, there is no control over whether it calls isc_commit_retaining
in commit.
and there no control over the isc_start_transaction arguments in rollback.

ideally i'd like to be able to specify the Default_Transaction_Parameters at connect time, and
also change them later at any time (as i can with AutoCommit).
This would be used in for transactions created automatically, whether
AutoCommit is on or off.
I'd also like the ability create transaction objects from perl, and pass in
transactions to use, so that no transaction is created at all for me (Default_Transaction_Parameters
is irrelevant). That would allow me to maintain multiple concurrent transactions from a single
client connection. 

These are the capabilities that caused my interest in this module to begin with.
They are critical to get good performance out of interbase.
As it is, my only reason to consider switching is if the memory corruption/leaking in IBPerl gets
too problematic.

Not that i'm not appreciative :).

-mda