On 21 Mar 2005 at 9:34, Ara.T.Howard wrote:
> this is not always true - on nfs for example. the only atomic ops on nfs are
> mkdir and symlink.
And flock if the filesystem supports it [as ReiserFS does].
/bernie\
--
Bernie Cosell Fantasy Farm Fibers
mailto:[EMAIL PROTECT
> yes this is the point. for sure it'd be better to use something else
> here -
> but there are certainly times when it would be nice to do atomic
> updates of
> sqlite dbs. without this ability you are bascially saying that, once
> a system
> goes into production you may never make big changes
On Fri, 18 Mar 2005, Eli Burke wrote:
How about using a second in-memory database for your modifications, then
using ATTACH to merge the changes. I'm fairly sure I remember Dr. Hipp
stating that moving complete rows between attached database tables is very
speedy. Depending on the particulars of yo
On Fri, 18 Mar 2005, Andrew Piskorski wrote:
If besides that one slow update you had ONLY READS (and those reads do not
care which version of the data they get, old or new), I'd say sure, fine, an
atomic "swap in a totally new db" operation might be worth trying.
But for a database with active read
On Fri, 18 Mar 2005, Lothar [unknown-8bit] Märkle wrote:
sqlite3_exec(db, "BEGIN EXCLUSIVE TRANSACTION", NULL, NULL, error);
copyFiles();
sqlite3_exec(db, "COMMIT", NULL, NULL, error);
i think you have to use sqlite3_close to be shure all
data is written. then copy.
Also are you sure it is complete
Andrew Piskorski wrote:
On Thu, Mar 17, 2005 at 08:33:03PM -0700, Ara.T.Howard wrote:
On Sat, 12 Mar 2005, Andrew Piskorski wrote:
On Sat, Mar 12, 2005 at 10:03:25AM -0700, Ara.T.Howard wrote:
does anyone have a strategy for doing massive updates to a db and atomicly
replacing it in
On Thu, Mar 17, 2005 at 08:33:03PM -0700, Ara.T.Howard wrote:
> On Sat, 12 Mar 2005, Andrew Piskorski wrote:
>
> >On Sat, Mar 12, 2005 at 10:03:25AM -0700, Ara.T.Howard wrote:
> >
> >>does anyone have a strategy for doing massive updates to a db and atomicly
> >>replacing it in a multi-process sit
On Fri, Mar 18, 2005 at 03:00:47PM +1100, Lars Norved wrote:
> Lothar M?rkle <[EMAIL PROTECTED]> writes:
> >>> Assuming you have a cgi-like application with many processes
> >>> that just looks up a row, displays and then exits. You can
> >>> simple use the rename call to atomically replace the d
Lothar Märkle <[EMAIL PROTECTED]> writes:
>>> Assuming you have a cgi-like application with many processes
>>> that just looks up a row, displays and then exits. You can
>>> simple use the rename call to atomically replace the db file
>>> (see man 2 rename for bordercases) with another and withou
On Sat, 12 Mar 2005, Andrew Piskorski wrote:
On Sat, Mar 12, 2005 at 10:03:25AM -0700, Ara.T.Howard wrote:
does anyone have a strategy for doing massive updates to a db and atomicly
replacing it in a multi-process situation?
Why would you want to do that? SQLite properly supports transactions, so
On Mon, Mar 14, 2005 at 11:50:45AM -0700, Ara T Howard wrote:
> > > does anyone have a strategy for doing massive updates to a db and
> > atomicly> replacing it in a multi-process situation?
> >
> > Assuming you have a cgi-like application with many processes that just
> > looks up a row, display
- Original Message -
From: Lothar M=E4rkle <[EMAIL PROTECTED]>
Date: Sunday, March 13, 2005 11:39 pm
Subject: Re: [sqlite] atomic db replacement
> > does anyone have a strategy for doing massive updates to a db and
> atomicly> replacing it in a multi-process situat
> does anyone have a strategy for doing massive updates to a db and atomicly
> replacing it in a multi-process situation?
Assuming you have a cgi-like application with many processes that just
looks up a row, displays and then exits. You can simple use the rename call
to atomically replace the db
On Sat, Mar 12, 2005 at 10:03:25AM -0700, Ara.T.Howard wrote:
> does anyone have a strategy for doing massive updates to a db and atomicly
> replacing it in a multi-process situation?
Why would you want to do that? SQLite properly supports transactions,
so aren't you better of just using those?
does anyone have a strategy for doing massive updates to a db and atomicly
replacing it in a multi-process situation?
cheers.
-a
--
===
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
|
15 matches
Mail list logo
