I wrote:
> I would still perform rollbacks for any errors other than the above
> expected SQLITE_BUSY cases, of course, since they indicate something
> else went wrong (such as running out of disk space). I think it's
> safe to say those are all unusual cases though.
Hmm,
On 10/29/07, Richard Klein <[EMAIL PROTECTED]> wrote:
> Perhaps the best solution is to follow these rules:
>
> IF THE TRANSACTION IS A WRITER (i.e. will eventually write to the db):
> --
> (1) Begin the transaction with 'BEGIN
Trevor Talbot wrote:
On 10/29/07, Richard Klein <[EMAIL PROTECTED]> wrote:
But am I correct in assuming that one way that SQLite provides
serializable transactions is by automatically rolling back
transactions when necessary (and returning SQLITE_IOERR)?
No. That will happen in some
On 10/29/07, Richard Klein <[EMAIL PROTECTED]> wrote:
> But am I correct in assuming that one way that SQLite provides
> serializable transactions is by automatically rolling back
> transactions when necessary (and returning SQLITE_IOERR)?
No. That will happen in some specific unavoidable
Its up to you to rollback the transaction.
It would return a SQLITE_BUSY, not an IOERR.
Richard Klein <[EMAIL PROTECTED]> wrote: But am I correct in assuming that one
way that SQLite provides
serializable transactions is by automatically rolling back
transactions when necessary (and returning
But am I correct in assuming that one way that SQLite provides
serializable transactions is by automatically rolling back
transactions when necessary (and returning SQLITE_IOERR)?
Thanks,
- Richard Klein
[EMAIL PROTECTED] wrote:
Ken <[EMAIL PROTECTED]> wrote:
BEGIN TRANSACTION;
SELECT
> This is true of SQLite because isolation in SQLite
> is "SERIALIZABLE". This is the highest level of isolate
> provided by SQL. Most client/server database engines
> by default implement "READ COMMITTED". The value of
> "balance" might change between the SELECT and the
> UPDATE in MySQL, for
On 10/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> This is true of SQLite because isolation in SQLite
> is "SERIALIZABLE". This is the highest level of isolate
> provided by SQL. Most client/server database engines
> by default implement "READ COMMITTED". The value of
> "balance"
Richard:
Actually No, process A will not acquire the reserved lock. It failes returning
a sqlite_busy, and must perform a rollback. Even if Process B commits. Process
A will get a sqlite_busy, forcing you to rollback.
In order for the application to be correct the entire transaction must be
That makes sense given SERIALIZABLE transactions.
The entire trasaction will require rollback since it gets a sqlite_busy, Not
just the update. This also has the effect of invalidating the data selected
within the transaction that performs the rollback.
Oracle defaults to Read Committed. But
Ken <[EMAIL PROTECTED]> wrote:
>
> BEGIN TRANSACTION;
> SELECT balance FROM accounts WHERE accountId = '123-45-6789';
> UPDATE accounts SET balance =
> WHERE accountId = '123-45-6789';
> COMMIT;
>
> This is a comman and naive assumption that the balance selected
> will
Richard Klein <[EMAIL PROTECTED]> wrote: Dan Kennedy wrote:
> On Wed, 2007-10-24 at 21:38 -0700, Richard Klein wrote:
>> As I was thinking about the locking mechanism in SQLite 3,
>> it occurred to me that the following race condition could
>> occur.
>>
>> Imagine a joint bank account with a
Trevor Talbot wrote:
On 10/25/07, Richard Klein <[EMAIL PROTECTED]> wrote:
Trevor Talbot wrote:
The thing is, SQLite's synchronization mechanism is simpler than most
full-featured SQL databases. In all cases, the point is that if you
are attempting to do simultaneous writes from two
On 10/25/07, Richard Klein <[EMAIL PROTECTED]> wrote:
> Trevor Talbot wrote:
> > The thing is, SQLite's synchronization mechanism is simpler than most
> > full-featured SQL databases. In all cases, the point is that if you
> > are attempting to do simultaneous writes from two connections, each
>
I am sure that you are correct, that Sqlite's sync mechanism is not
terribly complicated for you and for anyone else who understands the
principles, however it does confuse many users as you see from the
posts to this forum. Simple to use could become simpler to use.
Synchronizing
Dan Kennedy wrote:
On Wed, 2007-10-24 at 21:38 -0700, Richard Klein wrote:
As I was thinking about the locking mechanism in SQLite 3,
it occurred to me that the following race condition could
occur.
Imagine a joint bank account with a balance of $10,000.
The wife makes a withdrawal of $1,000
Trevor Talbot wrote:
The thing is, SQLite's synchronization mechanism is simpler than most
full-featured SQL databases. In all cases, the point is that if you
are attempting to do simultaneous writes from two connections, each
connection must be prepared to receive an error, rollback the
Lee Crain wrote:
I've wrapped all of my company's SQLite database accesses in my own API
layer that encapsulates all of our applications' business rules and forces
ALL transactions, no matter how lengthy or trivial, to be atomic by using
a MUTEX to avoid the types of scenarios described below.
The thing is, SQLite's synchronization mechanism is simpler than most
full-featured SQL databases. In all cases, the point is that if you
are attempting to do simultaneous writes from two connections, each
connection must be prepared to receive an error, rollback the
transaction, and try again.
You make a sound point. From my perspective the Sqlite synchronization
mechanisms are a flawed part of an otherwise elegantly simple design, as
reading this forum indicates. Synchronization problems are the major
item of confusion among users. A more robust and less intricate
interface
A classic solution to that problem is not to perform updates but to
insert transactions, The concept of log file systems to give
concurrency is worth scrutiny.
Richard Klein wrote:
As I was thinking about the locking mechanism in SQLite 3,
it occurred to me that the following race condition
Guys,
I read this forum regularly and I've given a lot of thought to all of
these conversations about low level logic and trying to squeeze the last
ounce of performance out of SQLite.
That's not for me. Simplicity equates to robustness and my company needs
robustness. And my time is really
On Wed, 2007-10-24 at 21:38 -0700, Richard Klein wrote:
> As I was thinking about the locking mechanism in SQLite 3,
> it occurred to me that the following race condition could
> occur.
>
> Imagine a joint bank account with a balance of $10,000.
> The wife makes a withdrawal of $1,000 at ATM 'A'
23 matches
Mail list logo
