Regarding Oracle:
It also batches commits... This means that if two or more users submit commits
concurrently (or near the same interupt ) then those will be serviced at the
same time.
But oracle differs significantly from sqlite, in its architecture as it would
not be appropriate for an
On Tue, Dec 26, 2006 at 09:36:42AM -0800, Ken wrote:
Your question boils down to this: Can you speed up transactions
by dropping the durable property - the D in ACID. Yes you
can. Actually, most client/server database engines already
do this for you without telling you. Very few
[EMAIL PROTECTED] uttered:
It takes at least two complete rotations of the disk platter
to do an atomic and durable commit. On a 7200 RPM disk, that
means 60 transactions per second is your speed of light.
Your question boils down to this: Can you speed up transactions
by dropping the
this type of code modification on SQLite :(
Probably I will need to do it myself...
Laszlo Elteto
-Original Message-
From: Jay Sprenkle [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 19, 2006 9:02 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] delayed (batch) transactions
On 12/19/06
On Wed, Dec 20, 2006 at 02:01:12AM +, [EMAIL PROTECTED] wrote:
Laszlo Elteto [EMAIL PROTECTED] wrote:
I DO need Durability, so I don't want to drop that. In fact, I need and want
normal transactional updates - just not immediately flushed to disk.
If the information is not flushed to
It is the same problem as trying to get a quart out of a pint bottle.
People looking for durability and higher performance might find that
using 15,000 RPM disks will do it without affecting durability or
requiring an application redesign. Experimentation with multiple disk
spindles so that
Elteto
-Original Message-
From: Nicolas Williams [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 20, 2006 9:43 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] delayed (batch) transactions
On Wed, Dec 20, 2006 at 02:01:12AM +, [EMAIL PROTECTED] wrote:
Laszlo Elteto [EMAIL
On Wed, Dec 20, 2006 at 01:22:06PM -0500, Laszlo Elteto wrote:
Nested transactions would solve my problem - but only if it worked across
different connections. As I said there are many transactions from various
clients, they may use multiple connections (eg. on a server). I think nested
Laszlo Elteto wrote:
Nested transactions would solve my problem - but only if it worked across
different connections. As I said there are many transactions from various
clients, they may use multiple connections (eg. on a server). I think nested
transactions would still be for ONE particular
I've started to use SQLite and it works fine - except for performance. The
application gets requests (possibly from many users) and does a few
transactions on the database. (eg. create a context for the request; later
it may be updated and when the user releases the record is deleted.)
I tried
Laszlo Elteto [EMAIL PROTECTED] wrote:
I've started to use SQLite and it works fine - except for performance. The
application gets requests (possibly from many users) and does a few
transactions on the database. (eg. create a context for the request; later
it may be updated and when the user
Laszlo Elteto wrote:
For this particular application it would NOT be a problem to lose like 2-5
seconds of transactions. I wonder if it is possible to tell SQLite to hold
off the transactions, ACCUMMULATE them until a certain time (or if cache
memory is exhausted - which is not yet the case as
On Tue, 19 Dec 2006 13:52:19 -0500, you wrote:
I've started to use SQLite and it works fine - except for performance. The
application gets requests (possibly from many users) and does a few
transactions on the database. (eg. create a context for the request; later
it may be updated and when the
have
to do the work myself IF it's already been done.)
Laszlo Elteto
SafeNet, Inc.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 19, 2006 11:15 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] delayed (batch) transactions
Laszlo Elteto
threads, then finish it from yet another thread.
Laszlo Elteto
SafeNet, Inc.
-Original Message-
From: Dennis Cote [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 19, 2006 11:30 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] delayed (batch) transactions
Laszlo Elteto wrote
]
Sent: Tuesday, December 19, 2006 12:08 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] delayed (batch) transactions
On Tue, 19 Dec 2006 13:52:19 -0500, you wrote:
I've started to use SQLite and it works fine - except for performance.
The application gets requests (possibly from many users
Laszlo Elteto [EMAIL PROTECTED] wrote:
I DO need Durability, so I don't want to drop that. In fact, I need and want
normal transactional updates - just not immediately flushed to disk.
If the information is not flushed to disk, how can it be durable?
--
D. Richard Hipp [EMAIL PROTECTED]
On 12/19/06, Laszlo Elteto [EMAIL PROTECTED] wrote:
For this particular application it would NOT be a problem to lose like 2-5
seconds of transactions. I wonder if it is possible to tell SQLite to hold
off the transactions, ACCUMMULATE them until a certain time (or if cache
memory is exhausted -
18 matches
Mail list logo
