On 20 Dec 2011, at 5:21pm, romtek wrote:
> I'd done some research into this since I asked my question and learned
> some things. According to http://bugs.php.net/bug.php?id=38182 and
> http://www.serverphorums.com/read.php?7,118071, PDO_SQLITE defaults to
> a 60 second busy timeout. This should
On Tue, Dec 20, 2011 at 6:08 AM, Simon Slavin wrote:
>
> First, there's more than one way of using SQLite3 from PHP. There's also the
> interface SQLite3:: which is a much thinner wrapper around the basic SQLite C
> library. I have no way of knowing what proportion of
On 20 Dec 2011, at 9:03am, romtek wrote:
> On Mon, Dec 19, 2011 at 1:34 PM, Pavel Ivanov wrote:
>>
>> Yes, this is expected behavior. In this case transaction won't be able
>> to ever proceed because it can proceed only when writing transaction
>> in session 1 is committed
On Mon, Dec 19, 2011 at 1:34 PM, Pavel Ivanov wrote:
>
> Yes, this is expected behavior. In this case transaction won't be able
> to ever proceed because it can proceed only when writing transaction
> in session 1 is committed but it cannot be committed until all reading
>
> 5. Enter the following in session 2 (demonstrates unexpected behavior):
>
> .timeout 1
> begin;
> select * from my_table;
> update my_table set userid=1;
>
> -> A 'database locked' error message is returned immediately.
>
> rollback;
>
> Is this the expected
I have observed a peculiar behavior for timeouts in transactions when
a transaction begins with a 'select' statement. Basically, it seems
like the timeout setting is not honored in this instance and if an
'update' statement follows the 'select' statement, a 'database locked'
error message is
6 matches
Mail list logo