I hope this arrives and gets moderated so someone can look at it.
I am trying to join the sqlite3-users list to ask a technical question but
I never receive a response from the Mailman (and no it isn't in my Spam
folder either).
I apologize if this is not the right address but I don't see an obvi
Ryan writes:
| just to be clear: It's not that SQLite commits after every
| statement - In SQLite, unless you have explicitly opened a
| transaction (using BEGIN), every statement is (and must be)
| in and of itself a transaction.
Right, I didn't say it committed after every statement, just
afte
On 9/27/17, pisymbol . wrote:
>
> I am trying to join the sqlite3-users list to ask a technical question but
> I never receive a response from the Mailman (and no it isn't in my Spam
> folder either).
>
I had Mailman set to notify me of subscription requests once per day.
So there was a delay. I
cc: OP
On 27 Sep 2017, at 4:31pm, pisymbol . wrote:
> I hope this arrives and gets moderated so someone can look at it.
Your mesage and replies to it reached the mailing list without probblems. If
you’re not seeing it there’s something wrong with your mail setup. Check your
junk folder and
On Thu, Sep 28, 2017 at 6:57 AM, Simon Slavin wrote:
> cc: OP
>
> On 27 Sep 2017, at 4:31pm, pisymbol . wrote:
>
> I hope this arrives and gets moderated so someone can look at it.
>
>
> Your mesage and replies to it reached the mailing list without probblems.
> If you’re not seeing it there’s s
On 9/28/17 7:03 AM, pisymbol . wrote:
On Thu, Sep 28, 2017 at 6:57 AM, Simon Slavin wrote:
cc: OP
On 27 Sep 2017, at 4:31pm, pisymbol . wrote:
I hope this arrives and gets moderated so someone can look at it.
Your mesage and replies to it reached the mailing list without probblems.
If you
Hello:
I have an application that makes heavy use of sqlite3 and during load
testing I very, very rarely (read: it has only happened once so far)
occasionally see the following error message:
"BEGIN EXCLUSIVE error: cannot start a transaction within a transaction"
I understand this error messag
On 28 Sep 2017, at 3:31pm, pisymbol . wrote:
> Specificially, if thread 1 and 2 both have a handle to sqlite3 with full
> mutex, then both could start a transaction simultaneously, one will win the
> other will wait, [snip]
By "serialised" the documentation means that no two SQL commands will
Hi, Simon,
On Thu, Sep 28, 2017 at 11:55 AM, Simon Slavin wrote:
>
>
> On 28 Sep 2017, at 3:31pm, pisymbol . wrote:
>
>> Specificially, if thread 1 and 2 both have a handle to sqlite3 with full
>> mutex, then both could start a transaction simultaneously, one will win the
>> other will wait, [sn
Hi,
it's a GMail issue, not mailman. GMail stops every returned email from
mailman which you have sent to it. GMail thinks "if you've sent this
message, it's already in your sent folder, and you don't want to see it
again in your inbox folder". It's stupid, but it's how gmail works :-(
I ha
On 28 Sep 2017, at 5:00pm, Igor Korot wrote:
> But the lock will be released on _finalize(), right?
Yes. Or on _reset(). Nevertheless, the transaction lasts until that point, so
the use of BEGIN, or the start of another SQLite one-statement transaction
cannot happen until then and will yie
On Thu, Sep 28, 2017 at 11:55 AM, Simon Slavin wrote:
>
>
> On 28 Sep 2017, at 3:31pm, pisymbol . wrote:
>
> > Specificially, if thread 1 and 2 both have a handle to sqlite3 with full
> > mutex, then both could start a transaction simultaneously, one will win
> the
> > other will wait, [snip]
>
On Thu, Sep 28, 2017 at 1:16 PM, pisymbol . wrote:
>
>
> On Thu, Sep 28, 2017 at 11:55 AM, Simon Slavin
> wrote:
>
>>
>>
>> On 28 Sep 2017, at 3:31pm, pisymbol . wrote:
>>
>> > Specificially, if thread 1 and 2 both have a handle to sqlite3 with full
>> > mutex, then both could start a transacti
On 28 Sep 2017, at 6:16pm, pisymbol . wrote:
> So even with full mutex, if I have thread 1 issue a "BEGIN" and it starts
> processing, and another thread 2 issues a "BEGIN" somewhere in between
> that, the other thread will just flat out fail because a transaction has
> already started for thre
On Thu, Sep 28, 2017 at 1:30 PM, Simon Slavin wrote:
>
>
> On 28 Sep 2017, at 6:16pm, pisymbol . wrote:
>
> > So even with full mutex, if I have thread 1 issue a "BEGIN" and it starts
> > processing, and another thread 2 issues a "BEGIN" somewhere in between
> > that, the other thread will just
Transactions are an attribute of the connection and the threads are irrelevant.
So once you BEGIN a transaction on a connection, that connection is inside a
transaction for any and all threads that may happen to use that connection.
---
The fact that there's a Highway to Hell but only a Stairw
On 28 Sep 2017, at 6:41pm, pisymbol . wrote:
> If you are using two different connections, then they both have to be
> opened with full mutex and then SQLite will serial accordingly. Is that
> right?
You’re right at the edge of my competency but I believe that is correct. My
understanding is
>> The follow-up to this is what is the purpose of full mutex mode and when
>> should it be used over no mutex mode?
>The mutex is useful when SQLite can tell that your commands are
>actually part of two separate efforts. i.e. when you’re using two
>different connections.
The mutex is used to pr
On 28 Sep 2017, at 6:57pm, Keith Medcalf wrote:
> The mutex is used to prevent multiple concurrent entry (ie, calling an
> sqlite3_* function) using the same connection from multiple threads. (ie,
> serialization). It does not provide isolation of any sort. THat is to say
> that you can pr
On Thu, Sep 28, 2017 at 2:10 PM, Simon Slavin wrote:
>
>
> On 28 Sep 2017, at 6:57pm, Keith Medcalf wrote:
>
> > The mutex is used to prevent multiple concurrent entry (ie, calling an
> sqlite3_* function) using the same connection from multiple threads. (ie,
> serialization). It does not prov
On 28 Sep 2017, at 8:01pm, pisymbol . wrote:
> So you can still have issues with thread 1 issuing a "BEGIN" and then
> thread 2 issuing another "BEGIN" before thread 1 finalizes the transaction
> causing failure. Correct?
Don’t know. Hope someone else does.
Simon.
___
Not if you use connection-per-thread model.
On Thu, Sep 28, 2017 at 3:07 PM, Simon Slavin wrote:
>
>
> On 28 Sep 2017, at 8:01pm, pisymbol . wrote:
>
>> So you can still have issues with thread 1 issuing a "BEGIN" and then
>> thread 2 issuing another "BEGIN" before thread 1 finalizes the transac
On Thu, Sep 28, 2017 at 3:11 PM, Igor Korot wrote:
> Not if you use connection-per-thread model.
>
>
Yes, right. That I understand and am in the midst of doing that right now.
-aps
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http
> On Sep 28, 2017, at 10:41 AM, pisymbol . wrote:
>
> If you are using two different connections, then they both have to be
> opened with full mutex and then SQLite will serial accordingly. Is that
> right?
SQLite connections are completely independent of each other; they share no
data* or fi
If they are both using the same connection, yes. Transaction state is an
attribute of the connection, not the statement or thread.
---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a
lot about anticipated traffic volume.
>-Original Message-
>From: sqlite-u
25 matches
Mail list logo
