What I want to say is in this example, there should be only one step,
because the transaction knows it will do 'write'.
Then the txn should start a write lock before the select.
And this is not a good example to explain dead lock, I think.
And again, you're talking about application using
2009/9/21 Pavel Ivanov paiva...@gmail.com
What I want to say is in this example, there should be only one step,
because the transaction knows it will do 'write'.
Then the txn should start a write lock before the select.
And this is not a good example to explain dead lock, I think.
And
I see. Thanks for your explaination.
May I ask if SQLite can explicitly start a write lock transaction ?
Yes. It's BEGIN IMMEDIATE or BEGIN EXCLUSIVE. The difference is that
IMMEDIATE still allows readers to read until actual writing to the
database file occurs (before that everything is
I was talking about this example by
2009/9/19 Igor Tandetnik itandet...@mvps.org
Imagine the
classic example, where a transaction first verifies that the balance in
a bank account is sufficient, then performs a withdrawal. If it
relinquishes all locks between these two steps, then somebody else
Wenbo Zhao wrote:
I was talking about this example by
2009/9/19 Igor Tandetnik itandet...@mvps.org
Imagine the
classic example, where a transaction first verifies that the balance
in a bank account is sufficient, then performs a withdrawal. If it
relinquishes all locks between these two
On Fri, 18 Sep 2009 14:27:00 -0400, Angus March
an...@uducat.com wrote:
Pavel Ivanov wrote:
Hell if I know why they use fcntl() for locks, and don't even give
you the option to block.
I think because they need to detect dead locks. BTW, I believe in case
of dead lock even busy_handler
Wenbo, are you talking about what do you want to see in DBMS or are
you trying to explain how SQLite works?
If the latter then you're wrong. In SQLite 'read lock' is designed for
transaction that _made_ any reads, 'write lock' - for transaction that
_made_ any writes.
Pavel
On Sat, Sep 19, 2009
I'm writing this system wherein I want operations performed on the
database to block when a lock cannot be achieved, and I'm looking at my
options. This system that has multiple processes accessing a single
sqlite file with a single database with a single table. I was
disappointed to find out
Since then I've come to realize that
sqlite doesn't have such a blocking feature. Is that correct?
Yes, that's correct.
I was thinking that a good solution would be to have a lock file,
with POSIX locks (I'm doing this in Linux) on it whenever one tries to
access the db in such a way
Pavel Ivanov wrote:
To be clear, my idea of blocking is as follows: if one tries to
achieve a lock, and it is not possible, the request is put into a queue,
and the caller stops consuming cycles. Locks are then granted (when
feasible) in the queue in the order that they were requested.
The kernel grants them: http://www.manpagez.com/man/2/flock . Or I
might use fcntl().
That's why I've asked what is different here from what SQLite already
does because SQLite uses fcntl() on database file already. You can try
to change it to flock() of course but be aware that SQLite needs
Pavel Ivanov wrote:
The kernel grants them: http://www.manpagez.com/man/2/flock . Or I
might use fcntl().
That's why I've asked what is different here from what SQLite already
does because SQLite uses fcntl() on database file already. You can try
Then it must use fcntl()
Pavel Ivanov wrote:
Hell if I know why they use fcntl() for locks, and don't even give
you the option to block.
I think because they need to detect dead locks. BTW, I believe in case
of dead lock even busy_handler will not be called, just SQLITE_BUSY is
returned...
I guess that
Angus March an...@uducat.com wrote:
Pavel Ivanov wrote:
Hell if I know why they use fcntl() for locks, and don't even give
you the option to block.
I think because they need to detect dead locks. BTW, I believe in
case of dead lock even busy_handler will not be called, just
SQLITE_BUSY is
I think because they need to detect dead locks. BTW, I believe in case
of dead lock even busy_handler will not be called, just SQLITE_BUSY is
returned...
I guess that makes sense, in cases where multiple tables are involved.
No, that makes sense when you're starting deferred transaction,
Pavel Ivanov wrote:
How does this preclude me from coming up w/my own lock file with
POSIX locks? If a bunch of process start making incompatible requests on
a single lock file, then they'll be queued and processed in order. I
don't see how you can have a deadlock when you have multiple
You mean you will lock this extra-file before doing any update and
unlock when update is done? Then ok, it will work. But again be aware
of possible dead locks.
You mean deadlocks are still possible in that scenario? How?
I mean just that I don't know exactly what do you want to do but
Angus March an...@uducat.com wrote:
Yes, I see. So what is key to the problem is that someone tries to
change their read lock to a write lock. I guess I just thought that
the kernel that manages fcntl() would have a way of dealing with
this. Can this situation not be averted if at step 3,
Igor Tandetnik wrote:
Angus March an...@uducat.com wrote:
Yes, I see. So what is key to the problem is that someone tries to
change their read lock to a write lock. I guess I just thought that
the kernel that manages fcntl() would have a way of dealing with
this. Can this situation not
This is not a good example i think.
If a transaction is intent to update after the select, it should start
a write lock before the select.
And as described in previous 'dead lock' example, the update in this
example could fail due to 'dead lock'
I believe the 'read lock' is designed for a 'read
20 matches
Mail list logo
