With Spring LDAP, how to reuse same connection and BIND across two LdapTemplate operations?












0















Here's the question:

How do I guarantee the same LDAP connection is used across subsequent LdapTemplate calls where LdapTemplate is instantiated with a PooledContextSource? It would be within the same transaction, if that matters.



Here's the background that led to the question:

My hope was that TransactionAwareContextSourceProxy would reuse the same TCP connection (bind) to the LDAP server across LdapTemplate calls within the same active transaction.



Looking at my LDAP server logs, this appears not to be the case. If I do a write then a lookup in the same transaction, I see BIND/MODDN/UNBIND/BIND/SEARCH/UNBIND in the server logs. The logs also show that the two BINDs are separate connections from the pool. There's no way this works for me because our LDAP cluster takes awhile to replicate between nodes (not to mention, it's just plain inefficient to rebind-per-op.)



Taking a closer look at the TransactionAwareContextSourceProxy documentation it says this:




A proxy for ContextSource to make sure that the returned DirContext
objects are aware of the surrounding transactions. This makes sure
that the DirContext is not closed during the transaction and that all
modifying operations are recorded, keeping track of the corresponding
rollback operations.




So it seems all that is really guaranteeing is connections aren't closed until commit time. Contrary to my hope, it doesn't guarantee the same connection across different LdapTemplate calls per-transaction.



I don't think a pool of SingleContextSource objects works either because I would expect LdapTemplate just pulls a different SingleContextSource from the pool for each op in the transaction.



EDIT:
I suppose I could do something like the following pseudo-code. I haven't tested this yet and I'll leave it to others to tell me if this is the best solution or not.



SingleContextSource singleContextSource = new SingleContextSource(pooledContextSource.getReadWriteContext());
try {
LdapTemplate ldapTemplate = new LdapTemplate(singleContextSource);
ldapTemplate.op1();
ldapTemplate.op2();
}
finally {
singleContextSource.destroy();
/* Whatever method needs to be called to return pooledContextSource to pool? Maybe singleContextSource.destroy() is enough to do that? */
}









share|improve this question





























    0















    Here's the question:

    How do I guarantee the same LDAP connection is used across subsequent LdapTemplate calls where LdapTemplate is instantiated with a PooledContextSource? It would be within the same transaction, if that matters.



    Here's the background that led to the question:

    My hope was that TransactionAwareContextSourceProxy would reuse the same TCP connection (bind) to the LDAP server across LdapTemplate calls within the same active transaction.



    Looking at my LDAP server logs, this appears not to be the case. If I do a write then a lookup in the same transaction, I see BIND/MODDN/UNBIND/BIND/SEARCH/UNBIND in the server logs. The logs also show that the two BINDs are separate connections from the pool. There's no way this works for me because our LDAP cluster takes awhile to replicate between nodes (not to mention, it's just plain inefficient to rebind-per-op.)



    Taking a closer look at the TransactionAwareContextSourceProxy documentation it says this:




    A proxy for ContextSource to make sure that the returned DirContext
    objects are aware of the surrounding transactions. This makes sure
    that the DirContext is not closed during the transaction and that all
    modifying operations are recorded, keeping track of the corresponding
    rollback operations.




    So it seems all that is really guaranteeing is connections aren't closed until commit time. Contrary to my hope, it doesn't guarantee the same connection across different LdapTemplate calls per-transaction.



    I don't think a pool of SingleContextSource objects works either because I would expect LdapTemplate just pulls a different SingleContextSource from the pool for each op in the transaction.



    EDIT:
    I suppose I could do something like the following pseudo-code. I haven't tested this yet and I'll leave it to others to tell me if this is the best solution or not.



    SingleContextSource singleContextSource = new SingleContextSource(pooledContextSource.getReadWriteContext());
    try {
    LdapTemplate ldapTemplate = new LdapTemplate(singleContextSource);
    ldapTemplate.op1();
    ldapTemplate.op2();
    }
    finally {
    singleContextSource.destroy();
    /* Whatever method needs to be called to return pooledContextSource to pool? Maybe singleContextSource.destroy() is enough to do that? */
    }









    share|improve this question



























      0












      0








      0








      Here's the question:

      How do I guarantee the same LDAP connection is used across subsequent LdapTemplate calls where LdapTemplate is instantiated with a PooledContextSource? It would be within the same transaction, if that matters.



      Here's the background that led to the question:

      My hope was that TransactionAwareContextSourceProxy would reuse the same TCP connection (bind) to the LDAP server across LdapTemplate calls within the same active transaction.



      Looking at my LDAP server logs, this appears not to be the case. If I do a write then a lookup in the same transaction, I see BIND/MODDN/UNBIND/BIND/SEARCH/UNBIND in the server logs. The logs also show that the two BINDs are separate connections from the pool. There's no way this works for me because our LDAP cluster takes awhile to replicate between nodes (not to mention, it's just plain inefficient to rebind-per-op.)



      Taking a closer look at the TransactionAwareContextSourceProxy documentation it says this:




      A proxy for ContextSource to make sure that the returned DirContext
      objects are aware of the surrounding transactions. This makes sure
      that the DirContext is not closed during the transaction and that all
      modifying operations are recorded, keeping track of the corresponding
      rollback operations.




      So it seems all that is really guaranteeing is connections aren't closed until commit time. Contrary to my hope, it doesn't guarantee the same connection across different LdapTemplate calls per-transaction.



      I don't think a pool of SingleContextSource objects works either because I would expect LdapTemplate just pulls a different SingleContextSource from the pool for each op in the transaction.



      EDIT:
      I suppose I could do something like the following pseudo-code. I haven't tested this yet and I'll leave it to others to tell me if this is the best solution or not.



      SingleContextSource singleContextSource = new SingleContextSource(pooledContextSource.getReadWriteContext());
      try {
      LdapTemplate ldapTemplate = new LdapTemplate(singleContextSource);
      ldapTemplate.op1();
      ldapTemplate.op2();
      }
      finally {
      singleContextSource.destroy();
      /* Whatever method needs to be called to return pooledContextSource to pool? Maybe singleContextSource.destroy() is enough to do that? */
      }









      share|improve this question
















      Here's the question:

      How do I guarantee the same LDAP connection is used across subsequent LdapTemplate calls where LdapTemplate is instantiated with a PooledContextSource? It would be within the same transaction, if that matters.



      Here's the background that led to the question:

      My hope was that TransactionAwareContextSourceProxy would reuse the same TCP connection (bind) to the LDAP server across LdapTemplate calls within the same active transaction.



      Looking at my LDAP server logs, this appears not to be the case. If I do a write then a lookup in the same transaction, I see BIND/MODDN/UNBIND/BIND/SEARCH/UNBIND in the server logs. The logs also show that the two BINDs are separate connections from the pool. There's no way this works for me because our LDAP cluster takes awhile to replicate between nodes (not to mention, it's just plain inefficient to rebind-per-op.)



      Taking a closer look at the TransactionAwareContextSourceProxy documentation it says this:




      A proxy for ContextSource to make sure that the returned DirContext
      objects are aware of the surrounding transactions. This makes sure
      that the DirContext is not closed during the transaction and that all
      modifying operations are recorded, keeping track of the corresponding
      rollback operations.




      So it seems all that is really guaranteeing is connections aren't closed until commit time. Contrary to my hope, it doesn't guarantee the same connection across different LdapTemplate calls per-transaction.



      I don't think a pool of SingleContextSource objects works either because I would expect LdapTemplate just pulls a different SingleContextSource from the pool for each op in the transaction.



      EDIT:
      I suppose I could do something like the following pseudo-code. I haven't tested this yet and I'll leave it to others to tell me if this is the best solution or not.



      SingleContextSource singleContextSource = new SingleContextSource(pooledContextSource.getReadWriteContext());
      try {
      LdapTemplate ldapTemplate = new LdapTemplate(singleContextSource);
      ldapTemplate.op1();
      ldapTemplate.op2();
      }
      finally {
      singleContextSource.destroy();
      /* Whatever method needs to be called to return pooledContextSource to pool? Maybe singleContextSource.destroy() is enough to do that? */
      }






      spring-ldap






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 28 '18 at 21:34







      acker9

















      asked Nov 28 '18 at 19:51









      acker9acker9

      6319




      6319
























          0






          active

          oldest

          votes












          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53527080%2fwith-spring-ldap-how-to-reuse-same-connection-and-bind-across-two-ldaptemplate%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          0






          active

          oldest

          votes








          0






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes
















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53527080%2fwith-spring-ldap-how-to-reuse-same-connection-and-bind-across-two-ldaptemplate%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Lallio

          Futebolista

          Jornalista