Jim,

As I understand You are talking about a journal to separate process (an
later to an external file). This would be great for some replication schemma
(one database is Master another - Slave like in MySQL) and if sources still
exists in Firebird it is quite enought I think to build internal replication
, so my idea would be worth not much. (IBReplicator exist but it is not Open
Source and free as I know. Could it be based on journaling process You
mention ?)
I was thinking about something different : how to use existing feature of
Interbase (record versioning) for avoid redo log completly.
Unfortunately I don't know InterBase source quite well, I'm rather database
manager and use InterBase as a programmer so maybe I misreported something.
The idea was to sign each record (or each transaction in TIP - keep in mind
that I don't know sources so I don't know what is better) with current
server timestamp and don't let database engine to throw away old committed
versions of record (as usual even without sweep) which timestamp is above
some limit (for example Now() - 12 hours).
This of course will cause database to grow fast (if this option is used) but
allow to get snaphot of records below requested timestamp (so it is internal
redo log).


Best Regards
Boguslaw

----- Original Message -----
From: "Jim Starkey" <jas@...>
To: <IB-Architect@yahoogroups.com>; <IB-Architect@yahoogroups.com>
Sent: Wednesday, September 04, 2002 8:54 PM
Subject: Re: [IB-Architect] Fw: [ib-support] One interesting idea (fixme if
I'm wrong)


> At 08:35 PM 9/4/02 +0200, =?iso-8859-2?Q?Bogus=B3aw_Brandys?= wrote:
> >>
> >> I've just read technical paper from Borland's Intebase Web about
> >Transaction
> >> Inventory Pages(TIP) , Oldest interesting Transaction (OIT) and Oldest
> >> Active Transaction (OAT) .
> >> Not all are clear for me, but I have an interesting idea.(at the user
> >point
> >> of view)
> >> Firebird is known from good shadowing and backup but do not have any
log
> >> file to rollback to some time point in the past .
> >>
> >> This is not quite exact , i think :-)
> >>
> >> I don't remember how this log is called in another database systems,but
> >is
> >> sometimes used becouse someone deleted critical information from
database
> >> (very bad database ;-) .
> >>
> >> Let me explain.
> >> Firebird database manager does good housekeeping with old versions of
> >> records,and here my idea occurs.
> >> Assume we have ordinary database which is not swept during day but at
> >night,
> >> and backup is done once a week.
> >> Define some server feature like "VANISH_TIMESTAMP":
> >> VANISH_TIMESTAMP 12 (default = 12 hours)
> >> Now all records should have not only transaction id but also a
timestamp
> >> when were created
> >> (sufficient is to store one double value for record).Alternatively all
> >> transactions in TIP could use timestamp, I don't know which is better
(?)
> >> When "VANISH_TIMESTAMP" is declared database manager should not delete
> >> committed records which are "younger " than 12 hours from now ,even if
are
> >> many such records.
> >> Gbak would have a feature to rollback database to some point in the
past
> >12
> >> hours.
> >> Making all records with timestamp also give us an option to easy
replicate
> >> database by just periodically check if there is new committed record
and
> >> replicate such record in another database (replication could stand
> >internal
> >> Firebird feature)
> >>
> >> This is of course an idea (and most of admins won't use it) but allows
> >many
> >> interesting things.
> >>
>
> Interbase actually had this functionality from the beginning of
> time until Borland's version 5. The database journalled either
> page changes or pages images (whichever was smaller) to a journal
> server process that could be shared across any number of database
> on a network.
>
> During development of version 5, some crackerjack manager had a hot
> idea on how to use the journal for a sequentially write redo log
> in case of system failure, apparently getting something for close
> to nothing. Unfortunately, when reviewed, it turned out that what
> he gave up was the very nice principle that when journalling was
> enable, a transaction wasn't reported as committed until the bits
> were safely written on two pieces of oxide, eliminating all danger
> from a single point of failure. So the old journalling system
> was pitched with the new one.
>
> I haven't checked the code, but there is no evidence that the
> Borland developers knew that text editors could also delete
> stuff from a source file, so I wouldn't be surprised if most
> of the code was present but latent. The journal subsystem
> itself was next to trivial, so re-writing it in modern C would
> make as much sense as an archeological dig.
>
> Journally has its problems, mostly the expense and gross
> unreliability of tape driver (oh, ugh). But a journal to
> a CDR or DVD-R drive might actually be worth thinking about.
>
> Jim Starkey
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>