cussion of SQLite Database
Subject: Re: [sqlite] begin transaction
> what is interesting is that proc B's 'item not found in locker!' is a read
> operation. so possibly i've (inadvertently) hit the 'shared lock upgrade to
> reserved lock' immediate fail.
>
of SQLite Database
Subject: Re: [sqlite] begin transaction
> what is interesting is that proc B's 'item not found in locker!' is a read
> operation. so possibly i've (inadvertently) hit the 'shared lock upgrade to
> reserved lock' immediate fail.
>
>
ite.org
> [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Pavel Ivanov
> Sent: Monday, November 23, 2009 7:36 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] begin transaction
>
>> That's true, but the comment is a bit deceptive, In this
>>
, November 23, 2009 7:36 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] begin transaction
> That's true, but the comment is a bit deceptive, In this
> particular case SQLite is supposed to invoke the busy-handler. What
> should happen is that SQLite grabs the SHARE
solution.
>>
>>
>> Pavel
>>
>> On Mon, Nov 23, 2009 at 9:15 AM, O'Neill, Owen > > wrote:
>>>
>>>
>>> Hi Tom,
>>>
>>> Whilst not knowing much about the process, I have a recollection
>>> about
>>>
Could that explain this ?
>>
>> Cheers
>> Owen
>>
>>
>>
>> -----Original Message-
>> From: sqlite-users-boun...@sqlite.org
>> [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Tom Broadbent
>> Sent: Friday, November 20, 2009 7:27 PM
&
s
> Owen
>
>
>
> -Original Message-
> From: sqlite-users-boun...@sqlite.org
> [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Tom Broadbent
> Sent: Friday, November 20, 2009 7:27 PM
> To: sqlite-users@sqlite.org
> Subject: [sqlite] begin transac
: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Tom Broadbent
Sent: Friday, November 20, 2009 7:27 PM
To: sqlite-users@sqlite.org
Subject: [sqlite] begin transaction
i have several processes all trying to write to a given DB. i have set
sqlite3_busy_timeout to
i have several processes all trying to write to a given DB. i have set
sqlite3_busy_timeout to 1 (10 sec). when proc A successfully beings a
trasaction IMMEDIATE what appears to happen when proc B attempts to begin
transaction IMMEDIATE is that it fails immediately w/ SQLITE_BUSY. i would
On 10/5/06, Levi Wilson <[EMAIL PROTECTED]> wrote:
I have a process that opens up a connection to my database when it starts up
with sqlite3_open. This connection is kept for the life of the process. In
one of my functions, it inserts a row into one table, and also into another
table that is re
"Levi Wilson" <[EMAIL PROTECTED]> wrote:
> please let me know if I have not been clear.
I, for one, do not understand what it is you are
trying to do.
--
D. Richard Hipp <[EMAIL PROTECTED]>
-
To unsubscribe, send email
I have a process that opens up a connection to my database when it starts up
with sqlite3_open. This connection is kept for the life of the process. In
one of my functions, it inserts a row into one table, and also into another
table that is related. Therefore, I wrap both statements within a "
Am Sonntag, 2. Juli 2006 20:53 schrieb Bud Beacham:
> I fixed this by enclosing RunQuery in a CATCH block. Now for another
> maximum stress test.
>
>
> #--
>--- proc RunQuery {resultDir dataBase query} {
I fixed this by enclosing RunQuery in a CATCH block. Now for another maximum
stress test.
#-
proc RunQuery {resultDir dataBase query} {
set P [format "$::FW" "([lindex [info level 0] 0
Bud Beacham <[EMAIL PROTECTED]> writes:
> In the book, SQLite (version 2.x of SQLite) by Chris Newman, he writes on
> page 184 that a way to test a Tcl callback function for a locked database is
> to issue a BEGIN TRANSACTION in one session and run the program in another
> session.
Note the boo
I am developing an Tcl app on Linux with SQLite (v3.3.5), and last night I
stressed tested it. Sure enough, one of process died with this error being
caught, "CATCH: database is locked".
In the book, SQLite (version 2.x of SQLite) by Chris Newman, he writes on
page 184 that a way to test
From: "Marcus Welz" <[EMAIL PROTECTED]>
Reply-To: sqlite-users@sqlite.org
To:
Subject: RE: [sqlite] BEGIN TRANSACTION name
Date: Thu, 3 Nov 2005 12:46:39 -0500
I actually have a question regarding nested transactions. Maybe I'm missing
something, but isn't it true that
or an in-house abstraction layer.)
Just wondering if I'm missing something critical.
Thanks.
-Original Message-
From: Marco Bambini [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 03, 2005 12:23 PM
To: sqlite-users@sqlite.org
Subject: [sqlite] BEGIN TRANSACTION name
In act
In actual version, the optional transaction name is ignored because
SQLite currently does not allow nested transactions.
Any plan to change this behavior in the near future?
Thanks,
Marco Bambini
Wilfried Mestdagh wrote:
Do I need the 'begin transaction' and 'commit' ?
No you don't need them unless you execute a number of linked SQL
commands and you need to ensure that either all of them succeed or none.
--
regards,
Alex Chudnovsky
Hello,
Do I need the 'begin transaction' and 'commit' ? It seems it works
without them also. I'm not sure I fully understeand wy I need them. If
someone can explain in simple English ?
I understeand that if I use them, and some serious error occures then
there is a rollback so that my application
On Oct 1, 2004, at 3:20 AM, Michael Roth wrote:
| I've been thinking about adding a PRAGMA that would cause this
| behavior. Another option is added a keyword to the end of BEGIN,
| for example "BEGIN EXCLUSIVE" or something like that.
The "BEGIN EXCLUSIVE" approach is very attractive.
That would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
D. Richard Hipp wrote:
| I've been thinking about adding a PRAGMA that would cause this
| behavior. Another option is added a keyword to the end of BEGIN,
| for example "BEGIN EXCLUSIVE" or something like that.
The "BEGIN EXCLUSIVE" approach is very at
b.bum wrote:
Is there a way to do a 'begin transaction' directly at the RESERVED
locking level?
I've been thinking about adding a PRAGMA that would cause this
behavior. Another option is added a keyword to the end of BEGIN,
for example "BEGIN EXCLUSIVE" or something like that.
--
D. Richard Hipp
I would suggest a dummy update or insert just after the BEGIN
TRANSACTION that does not do anything meaningful, just creates the
RESERVED lock.
On Sat, 2004-09-25 at 00:30, b.bum wrote:
> Is there a way to do a 'begin transaction' directly at the RESERVED
> locking level?
>
> A typical usage pat
Is there a way to do a 'begin transaction' directly at the RESERVED
locking level?
A typical usage pattern-- correct me if there is a better way-- is to:
- start a transaction (NO LOCK TAKEN)
- do a series of selects to gather or verify state (SHARED)
- do a series of inserts/updates (with inter
26 matches
Mail list logo
