This is the way I hoped it should work, and it does.
Thanks so much Igor!
-Alex
On Wed, Jul 2, 2008 at 9:39 PM, Igor Tandetnik <[EMAIL PROTECTED]> wrote:
> "Alex Katebi" <[EMAIL PROTECTED]>
> wrote in message
> news:[EMAIL PROTECTED]<[EMAIL PROTECTED]>
> > Below is a section from The Definitive
"Alex Katebi" <[EMAIL PROTECTED]>
wrote in message
news:[EMAIL PROTECTED]
> Below is a section from The Definitive Guide to SQLite book
> Is this not valid any more for the newer releases of SQLite.
This is not valid anymore. See the message from Dr. Hipp in this thread:
Below is a section from The Definitive Guide to SQLite book
Is this not valid any more for the newer releases of SQLite.
==
Table Locks
Even if you are using just one connection, there is a special edge case that
sometimes trips
people
Alex Katebi <[EMAIL PROTECTED]> wrote:
> Notice that I have multiple stmts stepping over the same table at
> the
> same time.
> Why is this OK?
Why shouldn't it be?
> There isn't a table level lock?
A file level lock, even. It happily locks out other connections (of
which you have none).
Igor,
Notice that I have multiple stmts stepping over the same table at the
same time.
Why is this OK? There isn't a table level lock?
When is a table locked?
Thanks,
-Alex
On Wed, Jul 2, 2008 at 5:12 PM, Igor Tandetnik <[EMAIL PROTECTED]> wrote:
> Alex Katebi <[EMAIL PROTECTED]>
Alex Katebi <[EMAIL PROTECTED]> wrote:
>> I created a test file. It is attached in this email. I can not see
>> any
>> locking happening at all.
Which part of "you should never experience any locking at all in this
scenario" did you find unclear the first time round? Why exactly are you
I created a test file. It is attached in this email. I can not see any
locking happening at all.
On Wed, Jul 2, 2008 at 4:25 PM, Igor Tandetnik <[EMAIL PROTECTED]> wrote:
> Alex Katebi <[EMAIL PROTECTED]> wrote:
> > Do I need to enable shared cache mode plus read uncommitted option?
>
> You
Alex Katebi <[EMAIL PROTECTED]> wrote:
> Do I need to enable shared cache mode plus read uncommitted option?
You only have one connection (one call to sqlite3_open), right? Then it
doesn't matter. "Shared" only makes a difference if there are at least
two connections to share between.
> Also
Do I need to enable shared cache mode plus read uncommitted option?
Also you mentioned earlier:
"(but you will experience "dirty reads" with all the attendant problems)."
What is a dirty read? What problems does it cause?
Thanks,
-Alex
On Wed, Jul 2, 2008 at 2:55 PM, Igor Tandetnik <[EMAIL
В сообщении от Wednesday 02 July 2008 22:42:48 Alex Katebi написал(а):
> Do you mean the sqlite3_busy_timeout( ) ?
> I never thought I could use it for simulating this.
> I will give that a shot.
Client don't get database busy error but sleep some time and execute query
later.
Alex Katebi <[EMAIL PROTECTED]> wrote:
> Just to make myself clearer. I have one memory connection and many
> stmts.
> Each stmt multiplexes the thread. This means that a stmt could give
> up the
> thread without finalizing itself.
That's OK. It used to be that, say, a SELECT statement in
Alexey,
Do you mean the sqlite3_busy_timeout( ) ?
I never thought I could use it for simulating this.
I will give that a shot.
Thanks,
-Alex
On Wed, Jul 2, 2008 at 11:40 AM, Alexey Pechnikov <[EMAIL PROTECTED]>
wrote:
> В сообщении от Wednesday 02 July 2008 19:11:58 Alex Katebi написал(а):
Just to make myself clearer. I have one memory connection and many stmts.
Each stmt multiplexes the thread. This means that a stmt could give up the
thread without finalizing itself.
On Wed, Jul 2, 2008 at 11:19 AM, Igor Tandetnik <[EMAIL PROTECTED]> wrote:
> Alex Katebi <[EMAIL PROTECTED]>
Alex Katebi <[EMAIL PROTECTED]> wrote:
> I have an in memory database and a single multiplexed thread for all
> readers and writes.
> I like to be able to read tables without locking out other readers and
> writers.
As far as I can tell, you do everything on a single thread using a
single
Hi Igor,
I have an in memory database and a single multiplexed thread for all
readers and writes.
I like to be able to read tables without locking out other readers and
writers.
Is this possible? I don't mind writers using locks but some of my readers
are slow and I don't want them to hold
Joanne Pham <[EMAIL PROTECTED]> wrote:
> I read the online document regarding "Table Level Locking" as below:
> At any one time, a single table may have any number of active
> read-locks or a single active write lock. To read data a table, a
> connection must first obtain a read-lock. To write to
Table level locking is used among statements for the same connection. File
level locking is used among connections. Your case is file level.
On Tue, Jul 1, 2008 at 8:00 PM, Joanne Pham <[EMAIL PROTECTED]> wrote:
> Hi All,
> I read the online document regarding "Table Level Locking" as below:
>
Hi All,
I read the online document regarding "Table Level Locking" as below:
At any one time, a single table may have any number of active
read-locks or a single active write lock. To read data a table, a connection
must first obtain a read-lock. To write to a table,
18 matches
Mail list logo
