Re: Transaction (was: Re: [Dbi-interbase-devel] Re: fixing InterBase.pm and IBPerl.pm for transactions)

[Edwin P. <ed....@co...>]

"Mark D. Anderson" wrote:
> cool.
> there are no sourceforge bugs, and the release notes just say "severe known problems are fixed".
> how close does it "feel" to you?

Never take it for granted, try it by yourself :-)
That's my laziness. But it's true that I've fixed previous known
problems (coredump). 

> > when AutoCommit is Off, for now I still use isc_commit_retaining().
> > Could you provide test cases to show that isc_commit_retaining() will
> > cause locking problems?
> 
> i don't know enough about how the interbase engine works to know what would
> show it, but this behavior certainly *should* cause starvation.
> the semantics of retaining is that the client connection retains locks on objects
> involved in the committed transaction. so if every commit retains locks, the client
> will gradually accumulate more and more locks, for as long as it lives.
> this will eventually cause either lock timeouts or deadlock, assuming that reasonable
> isolation levels are chosen.

I'll write some test scripts for this. Currently I'm focusing on fixing
problems encountered when running the test scripts. Getting basic
functionalities to work fine, and clean memory cleanups are my near
target.
The latest change was added support for InterBase 6.0 data types: date,
time, timestamp, and 64 bit numeric.

> > At this point, I have some notes that I'd like to discuss:
> > 1. other drivers (eg Oracle) use SET TRANSACTION sql command to specify
> > isolation level.
> 
> ib has a SET TRANSACTION as well, through i don't think there is any
> need for us to use it, since we can set all the flags via options.
> below is some xs code i sent karwin for use in IBPerl for creating transactions
> with arbitrary flags (currently IBPerl does not implement any parameters
> for txn creation).

I'm aware of this. the problem is where I should put these options.
Current implementation puts the interbase transaction handle within the
imp_dbh structure. Changing transaction parameters will affect all
statements from the same $dbh (DBI database handle).
Alternatively, we can put the trans handle within the imp_sth structure.
the consequence is there will be a separate transaction for each
statement, but we gain flexibility, because we can pass the transaction
parameters to the DBI prepare() method.

> > Because the hierarchy is: database handle -> transaction handle ->
> > statement handle, it seems that changing isolation level affects the
> > whole statement handle (within the same DBI dbh).
> 
> i wouldn't say that is the hierarchy.
> after all statements can be prepared and cached, and used in multiple transactions.
> if i were going to turn autocommit off, i would want to be able to have multiple
> transaction objects at once, and create them myself with parameters of my choosing,
> and pass them in to execute().

I'll address this issue after the test scripts are ready.

Rgds,
Edwin.