According to the documentation :
"database connection in read-uncommitted mode does not attempt to obtain
read-locks before reading from database tables as described above. This can
lead to inconsistent query results if another database connection modifies a
table while it is being read, but it
> I meant the mutex that is a member of the BtShared struct
> (BtShared.mutex). Grabbed by the call to sqlite3VdbeMutexEnterArray()
> at the top of sqlite3VdbeExec() and not released until that function
> returns.
Okay, now I see that and I don't like it at all. Of course it doesn't
eliminate
On Nov 18, 2009, at 10:03 PM, Pavel Ivanov wrote:
> I don't know what Dan meant by his words but AFAIK there's no mutex
> making exclusive grab of shared cache by sqlite3_step() call. There is
> only mutex making sqlite3_step() execution exclusive for connection
> object.
I meant the mutex that
I don't know what Dan meant by his words but AFAIK there's no mutex
making exclusive grab of shared cache by sqlite3_step() call. There is
only mutex making sqlite3_step() execution exclusive for connection
object.
Pavel
On Wed, Nov 18, 2009 at 8:40 AM, presta wrote:
>
> I'm
I'm confused according to Dan Kennedy :
"Each shared-cache has its own mutex. The mutex is held for the duration
of each sqlite3_step() call. So the way you're defining it here, you
can't have "real" concurrency when using shared-cache mode in any case. "
So, it's a little bit "antagonist" to
Shared cache instance is created on file-by-file basis, i.e. if you
open connections to file1.db and file2.db they will have different
cache instances and any manipulations with these database files won't
influence one another at all (any write operations can be executed in
parallel). But if you
To be more precise I would like to parallelize writes operations on different
tables, so potentially in different db (files).
It's why I think about using multi databases (1 by table), the shared cache
system and the asynchronized I/O..
So if a shared cache is shared accross different
>> So, does it possible to have more than one shared cache within a single
>> process ?
>
> Open the same database twice, using two different handles. At least I think
> it will work.
Nope, it won't. That's the purpose of shared cache: if you open the
same database several times with different
Thanks,
I will try to use the shared cache with Async I/O
"Each shared-cache has its own mutex"...
So, does it possible to have more than one shared cache within a single
process ?
One shared cache by db ?
--
View this message in context:
On Nov 18, 2009, at 1:25 PM, presta wrote:
>
> Hello,
>
> I'm wondering if shared cache and read uncommited isolation level with
> asyncronous I/O enabled is possible ?
I haven't tried, but I assume it is possible. The two features don't
really interact.
> In sqlite3async.c I see a shared
Hello,
I'm wondering if shared cache and read uncommited isolation level with
asyncronous I/O enabled is possible ?
In sqlite3async.c I see a shared mutex between read and write operations, so
I doubt that it is possible to have real concurrency between read and
write...
Regards
--
View
Hello,
I'm wondering if shared cache and read uncommited isolation level with
asyncronous I/O enabled is possible ?
In sqlite3async.c I see a shared mutex between read and write operations, so
I doubt that it is possible to have real concurrency between read and
write...
Regards
--
View
12 matches
Mail list logo