Hello all.

I need to support multiple rollback points / savepoints and am
wondering if there is some easy way to do this with berkeley.
I used the terms rollback and savepoints, but I dont think my
scenario is exactly like either...

Specifically, I need to be able to run a batch type job that updates
the db and at certain intervals commits its changes and associates
those changes with an id (commit / savepoint / checkpoint id etc.)
Say the job took 3 commits: commit1, commit2, and commit3. The job
then fails and for whatever application specific reason, the db needs
to be rolled back to "commit2" or "commit1".

Note that I'm not looking for parent / child transactions. I need each
commit to be flushed to db and available for other processes, etc.

I guess it's basically point in time rollback (as long as associated
logs are available.) I need to be able to start the job at point X,
where X is some spot that it did a data commit.

I saw DB_ENV->set_tx_timestamp, but it only appears to be for recovery.

Thanks for any ideas.

-casey

Casey,

If you release locks for other transactions then there is no
way to be sure you can back out a change, since other
transactions my update the data.

If it is the case that the other transactions are read only
then you might consider if DB_DIRTY_READ locking gets you what
you want along with child transactions.

If dirty reading is not acceptable there is no facility in Berkeley DB
that directly provides the functionality that you want. You could
implement it by writing change descriptions to a separate database
so that you can use that to back out your changes.

Michael Ubell
Sleepycat Software.

Thanks Michael. Hope you dont mind some further questions.

Michael Ubell wrote:

I was hoping that i could use the "change description" information
that is already in the db log.

If I kept around the transaction id, could i rollback to that
transaction id? I was poking around the code a little and came
across:

/*
* __db_apprec --
* Perform recovery. If max_lsn is non-NULL, then we are trying
* to synchronize this system up with another system that has a max
* LSN of max_lsn, so we need to roll back sufficiently far for that
* to work. See __log_backup for details.
*
* PUBLIC: int __db_apprec __P((DB_ENV *, DB_LSN *, u_int32_t));
*/
int
__db_apprec(dbenv, max_lsn, flags)
DB_ENV *dbenv;
DB_LSN *max_lsn;
u_int32_t flags;


As documented, the max_lsn parm didn't appear to be used for normal
recovery, but it did appear to be used to sync up remote master/client
databases. Maybe I could use DB_ENV->log_put() to get a lsn for
later use with __db_apprec or something similar. I know I'm getting
into the internals here - that's ok with me. Just wondering if
I might be on the right path.

-casey

Casey,

__db_apprec is only run from recovery and is assumed to be running
single threaded so what you are proposing will not work without
much effort. Even when called from replication that inteface requires
no other threads in the database.

If you have a single updating thread I could IMAGINE reading through
the log and calling the recovery routines to back out changes.
IMAGINE is the key word here, things dealing with the recovery
code always turn out to be more complicated than one could imagine.
If you have multiple updating threads, then I don't think
it could be made to work.

Michael Ubell
Sleepycat Software.