<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 08/07/2015 05:54 PM, William Brown
wrote:<br>
</div>
<blockquote cite="mid:1438991656.25626.110.camel@blackhats.net.au"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
Say for example:
begin
add some object Y
read Y
commit
Does read Y see the object within the transaction?
</pre>
</blockquote>
<pre wrap="">
Yes.
</pre>
<blockquote type="cite">
<pre wrap="">Is there a way to make the
search happen so that it occurs outside the transaction, IE it doesn't see
Y?
</pre>
</blockquote>
<pre wrap="">
Not a nested search operation. A nested search operation will always
use the parent/context transaction.
</pre>
</blockquote>
<pre wrap="">
Makes sense. Just wanted to clarify so that I understood how different apis etc
will behave within a betxn context.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
Is there a piece of documentation (perhaps the plugin guide) that lists the
order in which these operations are called?
</pre>
</blockquote>
<pre wrap="">
Not sure, but in general it is:
incoming operation from client
front end processing
preoperation
call backend
bepreoperation
start transaction
betxnpreoperation
do operation in the database
betxnpostoperation
end transaction
bepostoperation
return from backend
send result to client
postoperation
</pre>
</blockquote>
<pre wrap="">
I found this list in the Redhat Directory Services Plugin Development guide, but
thank you for it as well.
So with the transaction, there is only one transaction that covers all betxn
plugins?</pre>
</blockquote>
<br>
Yes and no. Yes, there is only one parent transaction corresponding
to the initial database interaction from the original top level
incoming client operation. However, each plugin will create a
nested transaction for its write. For example, a top level modify
operation will create a top level parent database transaction, and
may cause the memberof plugin to trigger and write. The nested
memberof plugin operation will create a nested child transaction
using the original top level transaction as the parent.<br>
<br>
Note that all of these transactions are created/managed without any
knowledge or participation of plugin code - the database code
manages all of this for the plugins.<br>
<br>
<blockquote cite="mid:1438991656.25626.110.camel@blackhats.net.au"
type="cite">
<pre wrap="">And I also wouldn't need to do anything to start / end the transaction
within a plugin either do I?</pre>
</blockquote>
<br>
No.<br>
<br>
<blockquote cite="mid:1438991656.25626.110.camel@blackhats.net.au"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">The toughest part is the deadlock prevention. At the start transaction,
it holds a DB lock. And most plug-ins maintain its own mutex to protect
its resource. It'd easily cause deadlock situation especially when
multiple plug-ins are enabled (which is common :). So, please be careful
not to acquire/free locks in the wrong order...
</pre>
</blockquote>
<pre wrap="">Of course. This is always an issue in multi-threaded code and anything with
locking. Stress tests are probably good to find these deadlocks, no?
</pre>
</blockquote>
<pre wrap="">
Yes. There is some code in dblayer.c that will stress the transaction
code by locking/unlocking many db pages concurrently with external
operations.
<a class="moz-txt-link-freetext" href="https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/servers/slapd/back-ldbm">https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/servers/slapd/back-ldbm</a>
/dblayer.c#n210
<a class="moz-txt-link-freetext" href="https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/servers/slapd/back-ldbm">https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/servers/slapd/back-ldbm</a>
/dblayer.c#n4131
</pre>
</blockquote>
<pre wrap="">
Are there some unit tests hooked up that call and test this?</pre>
</blockquote>
<br>
No, not afaik.<br>
<br>
<blockquote cite="mid:1438991656.25626.110.camel@blackhats.net.au"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">That answers some of my question. I guess the larger part of the question is
how
the plugin subsystem treats each pluginType differently and the value of
having
a plugin register to more than one pluginType. Are there some documents you
can
point me to about this?
</pre>
</blockquote>
<pre wrap="">
I'm not sure if there are docs which answer your specific question. But
a plugin may want to perform tasks at different points in the
operation. For example, DNA may want to generate a unique value in the
pretxn phase, then roll back that value in the posttxn phase if the
operation failed. Replication wants to many tasks at many different
points in the operation.
</pre>
</blockquote>
<pre wrap="">
That makes sense.
Again, I found some documents about this in the plugin developers guide, and
I've re-read some other plugin code so I have a better grasp of this now.
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
Additionally, with betxn, this seems quite black-or-white. It's either on a
ds
instance that has betxn support, so every update will be betxn capable, or
it's
not on such a system so you fall back to other methods. Is this correct?
With
new plugins is it even worth writing them without betxn support?
</pre>
</blockquote>
<pre wrap="">
Correct. It is not even worth writing a new plugin without betxn
support, if it does any update to the database that depends on other
updates to the database triggered by the incoming operation from the client.
</pre>
</blockquote>
<pre wrap="">
Fantastic. Thanks for the clarification.
For reference here is the plugin that this message references. It was a simple
demo to just get my head into plugin writing from scratch. I'm happy to accept
comments about it. I know that as a feature it's useless because
nsDS5ReplicaType already covers the use case, but it's a nice simple exercise
none the less.</pre>
</blockquote>
<br>
Sure. It is a complex area, so questions are expected and
encouraged.<br>
<br>
<blockquote cite="mid:1438991656.25626.110.camel@blackhats.net.au"
type="cite">
<pre wrap="">
Thanks for your time.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
389-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:389-devel@lists.fedoraproject.org">389-devel@lists.fedoraproject.org</a>
<a class="moz-txt-link-freetext" href="https://admin.fedoraproject.org/mailman/listinfo/389-devel">https://admin.fedoraproject.org/mailman/listinfo/389-devel</a></pre>
</blockquote>
<br>
</body>
</html>