Stefan Sperling <stsp_at_elego.de> writes:
> On Tue, Mar 15, 2011 at 10:26:15AM +0000, Philip Martin wrote:
>> Branko Čibej <brane_at_e-reka.si> writes:
>>
>> > The restriction that you may not invoke a callback from within a sqlite
>> > transaction remains. That's what the temporary results tables are for --
>> > they live outside transactions on the main wc-db.
>>
>> I don't understand the temporary table approach. Taking the
>> temp__node_props_cache table as an example: it gets populated by a
>> transaction and lives beyond that transaction. The table then gets
>> queried by a second transaction and the callbacks are made while that
>> second transaction is in progress. So callbacks are still being invoked
>> from within a transaction.
>
> It works around the infinite loop problem that happens when the
> callback inserts rows that end up being picked up by the proplist query.
> Which is silly for this callback to do, but then again we somehow agreed
> that the callbacks are free to do virtually anything. (I still think
> putting newly documented restrictions on them now is fine and would make
> our life easier... *shrug*).
I'm still confused. I thought the infinite loop problem affected the
old multiple transaction code. If we simply ran a single transaction
and made callbacks then that problem would not exist. We would have the
same limitations that apply to the temporary table approach: the
callback cannot write to the database because a transaction is in
progress.
>> As far as I can see using a temporary table has made the overall "read
>> properties" operation into one that modifies the database, to create the
>> temporary table. I guess that by the time the callbacks are made the
>> database write-lock has been dropped, but there would have been no
>> write-lock if the temporary table were not used.
>
> I think the temporary table gets put into a separate database file
> (or memory, depending on the temp_store pragma or whatsitcalled).
> If so, a read lock on the primary db should suffice, shouldn't it?
Yes, by the time we invoke the callbacks we have a read-lock. If we
simply ran a single transaction and made callbacks within the
transaction then it would have the same effect. I don't see what the
temporary table achieves.
--
Philip
Received on 2011-03-15 13:53:17 CET