SQLite and DBM::Deep transactions

[Rob Kinyon]

Gah! I don't think SQLite will support DBM::Deep transactions. The
problem, as I understand it, is best demonstrated by line 67 of
t/33_transactions.t - we have $db1 and $db2 both open against the same
DBM::Deep db. We then have the following statements:

$db1->{x} = 'y';

is( $db1->{x}, 'y', "No transaction started - DB1's X is Y" );
is( $db2->{x}, 'y', "No transaction started - DB2's X is Y" );

$db1->begin_work

is( $db1->{x}, 'y', "DB1 transaction started, no actions - DB1's X is Y" );
is( $db2->{x}, 'y', "DB1 transaction started, no actions - DB2's X is Y" );

$db2->{x} = 'a';
is( $db1->{x}, 'y', "Within DB1 transaction, DB1's X is still Y" );
is( $db2->{x}, 'a', "Within DB1 transaction, DB2's X is now A" );

As I understand SQLite (which isn't expert-level, I admit), this is
because there is a RESERVED lock taken against the DB by $db1. This
means that $db2 can't write until $db1 exits the transaction.

Can anyone help?

This, btw, is not where InnoDB fails. *sighs*

--
Thanks,
Rob Kinyon

[Paul Miller]

> As I understand SQLite (which isn't expert-level, I admit), this is
> because there is a RESERVED lock taken against the DB by $db1. This
> means that $db2 can't write until $db1 exits the transaction.
>
> Can anyone help?

I can't help, except to say that it sounds right...

My SQLite-foo is pretty week, but I know every time I start getting
complicated with transactions and locking I get mad and switch to a
different platform. It's really set up for single threaded
embedded-style situations.

-Paul

--
If riding in an airplane is flying, then riding in a boat is swimming.
114 jumps, 47.2 minutes of freefall, 90.4 freefall miles.