#289 allow betxn plugin config changes
Closed: wontfix None Opened 9 years ago by rmeggins.

There are a few plugins that can be configured both by the cn=config tree and the regular DIT. These plugins use the pre/post operation callbacks to manage both of these. However, when the plugin is a betxn post operation plugin, the post operation callback is not called for cn=config changes. For these, we need to use a DSE post op callback.


easier to read patch with whitespace-only changes removed
no-whitespace.patch

Your patches look good.

I have one question regarding how to write plugin... Assuming the operation is against the ldbm backend, if some updates are made in be pre op, we could expect the change is "rollback"ed if the operation fails. That is, the (be) post op does not have to worry about undoing the change. Currently, USN does not use be pre/post op, and the post op does undo the change if the op fails. Once we move it to be txn, we could get rid of the undo code, I guess. Here, USN is not a good example, since it does not work on the entries in DSE, but if there were such a plugin working on both the DSE and ldbm backend, the plugin does not have to do undoing the change made in the be preop even if the target entry is a DSE one?

In general, we only call be preop and be txn preop if the previous
callbacks and other checking succeeded. We always call the be and
be txn postop callbacks, even upon error, because there are some be
and be txn postops that need to know if there was an error so they
can "rollback" - usn, dna, replication to cancel pending csn, etc.

Replying to [comment:4 nhosoi]:

Your patches look good.

I have one question regarding how to write plugin... Assuming the operation is against the ldbm backend, if some updates are made in be pre op, we could expect the change is "rollback"ed if the operation fails. That is, the (be) post op does not have to worry about undoing the change.

If the changes are changes to the database, then correct, postop does not have to worry about anything - either the changes will be written by commit or rolled back by abort.

If however the changes are made to some global structure outside of the database (e.g. usn counter, dna range, etc.) the plugin will need to "rollback" its changes. In order to do this, I implemented your support for "abort" callbacks - that is, the betxn postop plugins will be called just before abort, with the appropriate error codes set in SLAPI_RESULT_CODE and SLAPI_PLUGIN_OPRETURN, so that the plugin will know that it needs to do some sort of internal rollback, and is guaranteed that this will happen while protected by the transaction lock.

Currently, USN does not use be pre/post op, and the post op does undo the change if the op fails. Once we move it to be txn, we could get rid of the undo code, I guess.

Not sure what you mean - usn_bepostop()?

Here, USN is not a good example, since it does not work on the entries in DSE, but if there were such a plugin working on both the DSE and ldbm backend, the plugin does not have to do undoing the change made in the be preop even if the target entry is a DSE one?

There are no "transactions" in the DSE code. We just call the be and betxn plugins in roughly the same places as they are called in the ldbm code, to try to preserve the semantics as much as possible, so that we can easily convert a pre/post op plugin to be a betxn pre/post op plugin.

In general, we only call be preop and be txn preop if the previous
callbacks and other checking succeeded. We always call the be and
be txn postop callbacks, even upon error, because there are some be
and be txn postops that need to know if there was an error so they
can "rollback" - usn, dna, replication to cancel pending csn, etc.

Thank you, Rich. You gave me the answer I wanted to have, I think.

If however the changes are made to some global structure outside of the database (e.g. usn counter, dna range, etc.) the plugin will need to "rollback" its changes.

The outside of the database include DSEs (dna range is stored there, right?)

And yes, my "ack" is still alive.

Replying to [comment:6 nhosoi]:

Thank you, Rich. You gave me the answer I wanted to have, I think.

If however the changes are made to some global structure outside of the database (e.g. usn counter, dna range, etc.) the plugin will need to "rollback" its changes.

The outside of the database include DSEs (dna range is stored there, right?)

Right. The DSE database won't rollback transactions since it's not transacted.

And yes, my "ack" is still alive.

To ssh://git.fedorahosted.org/git/389/ds.git
93adf5f..0594d5f master -> master
commit changeset:0594d5f/389-ds-base
Author: Rich Megginson rmeggins@redhat.com
Date: Mon Feb 13 11:31:15 2012 -0700

Added initial screened field value.

Metadata Update from @nhosoi:
- Issue assigned to rmeggins
- Issue set to the milestone: 1.2.11.a1

4 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/289

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

8 months ago

Login to comment on this ticket.

Metadata