With Spring LDAP, how to reuse same connection and BIND across two LdapTemplate operations?
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
add a comment |
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
add a comment |
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
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
spring-ldap
edited Nov 28 '18 at 21:34
acker9
asked Nov 28 '18 at 19:51
acker9acker9
6319
6319
add a comment |
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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