>> > So is such behavior documented and can be used or should I still avoid
>> > keeping such "live" statements in db-shared enviroment?
>>
>> It's documented that sqlite3_finalize AND sqlite3_reset release all
>> locks acquired by the statement. So after resetting the statement you
>> can keep it
On Thu, Feb 25, 2010 at 6:53 PM, Pavel Ivanov wrote:
> > So is such behavior documented and can be used or should I still avoid
> > keeping such "live" statements in db-shared enviroment?
>
> It's documented that sqlite3_finalize AND sqlite3_reset release all
> locks acquired
> So is such behavior documented and can be used or should I still avoid
> keeping such "live" statements in db-shared enviroment?
It's documented that sqlite3_finalize AND sqlite3_reset release all
locks acquired by the statement. So after resetting the statement you
can keep it as long as you
Hi,
I thought that prepared statements in non-finalized state isn't compatible
with locking mechanism in db sharing environment i.e. if I want for any of
several processes not to hang waiting for EXCLUSIVE lock none of others
should use non-finalized prepared statements. But today I found that
4 matches
Mail list logo