unbind("'ou=DEPT_NAME, o=ORG_NAME", true) in transaction throws Exception,is BUG?

[andrawu]

dn="'ou=DEPT_NAME, o=ORG_NAME" has two sub dn,one is 'ou=ONE, ou=DEPT_NAME, o=ORG_NAME', the other is 'ou=TWO, ou=DEPT_NAME, o=ORG_NAME' , invoke unbind("'ou=DEPT_NAME, o=ORG_NAME", true) in transaction throws Exception，invoke unbind("'ou=DEPT_NAME, o=ORG_NAME", true) not in transaction is OK!

org.springframework.ldap.ContextNotEmptyException: [LDAP: error code 66 - subtree rename not supported]; nested exception is javax.naming.ContextNotEmptyException: [LDAP: error code 66 - subtree rename not supported]; remaining name 'ou=DEPT_NAME, o=ORG_NAME'
javax.naming.ContextNotEmptyException: [LDAP: error code 66 - subtree rename not supported]; remaining name 'ou=DEPT_NAME, o=ORG_NAME'
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.jav a:3020)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCt x.java:2931)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCt x.java:2737)
at com.sun.jndi.ldap.LdapCtx.c_rename(LdapCtx.java:68 5)
at com.sun.jndi.toolkit.ctx.ComponentContext.p_rename (ComponentContext.java:693)
at com.sun.jndi.toolkit.ctx.PartialCompositeContext.r ename(PartialCompositeContext.java:251)
at javax.naming.InitialContext.rename(InitialContext. java:389)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.ldap.transaction.compensating. LdapCompensatingTransactionOperationFactory$NonClo singDirContextInvocationHandler.invoke(LdapCompens atingTransactionOperationFactory.java:188)
at $Proxy10.rename(Unknown Source)
at org.springframework.ldap.core.LdapTemplate$29.exec uteWithContext(LdapTemplate.java:1162)
at org.springframework.ldap.core.LdapTemplate.execute WithContext(LdapTemplate.java:784)
at org.springframework.ldap.core.LdapTemplate.execute ReadWrite(LdapTemplate.java:779)
at org.springframework.ldap.core.LdapTemplate.rename( LdapTemplate.java:1159)
at org.springframework.ldap.transaction.compensating. UnbindOperationExecutor.performOperation(UnbindOpe rationExecutor.java:92)
at org.springframework.transaction.compensating.suppo rt.DefaultCompensatingTransactionOperationManager. performOperation(DefaultCompensatingTransactionOpe rationManager.java:69)
at org.springframework.transaction.compensating.suppo rt.CompensatingTransactionUtils.performOperation(C ompensatingTransactionUtils.java:63)
at org.springframework.ldap.transaction.compensating. manager.TransactionAwareDirContextInvocationHandle r.invoke(TransactionAwareDirContextInvocationHandl er.java:87)
at $Proxy10.unbind(Unknown Source)
at org.springframework.ldap.core.LdapTemplate.deleteR ecursively(LdapTemplate.java:1106)
at org.springframework.ldap.core.LdapTemplate$26.exec uteWithContext(LdapTemplate.java:1078)
at org.springframework.ldap.core.LdapTemplate.execute WithContext(LdapTemplate.java:784)
at org.springframework.ldap.core.LdapTemplate.execute ReadWrite(LdapTemplate.java:779)
at org.springframework.ldap.core.LdapTemplate.doUnbin dRecursively(LdapTemplate.java:1075)
at org.springframework.ldap.core.LdapTemplate.unbind( LdapTemplate.java:1041)
at com.landray.kmss.ldap.common.dao.BaseDaoImpl.delet e(BaseDaoImpl.java:74)
at com.landray.kmss.ldap.common.service.BaseServiceIm pl.delete(BaseServiceImpl.java:53)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.springframework.aop.support.AopUtils.invokeJoi npointUsingReflection(AopUtils.java:287)
at org.springframework.aop.framework.ReflectiveMethod Invocation.invokeJoinpoint(ReflectiveMethodInvocat ion.java:181)
at org.springframework.aop.framework.ReflectiveMethod Invocation.proceed(ReflectiveMethodInvocation.java :148)
at org.springframework.transaction.interceptor.Transa ctionInterceptor.invoke(TransactionInterceptor.jav a:96)
at org.springframework.aop.framework.ReflectiveMethod Invocation.proceed(ReflectiveMethodInvocation.java :170)
at org.springframework.aop.framework.JdkDynamicAopPro xy.invoke(JdkDynamicAopProxy.java:176)
at $Proxy3.delete(Unknown Source)
at com.landray.kmss.ldap.organization.dao.LdapOrgOrgD aoTestCase.testDeleteData(LdapOrgOrgDaoTestCase.ja va:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154 )
at junit.framework.TestCase.runBare(TestCase.java:127 )
at junit.framework.TestResult$1.protect(TestResult.ja va:106)
at junit.framework.TestResult.runProtected(TestResult .java:124)
at junit.framework.TestResult.run(TestResult.java:109 )
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:2 08)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit 3TestReference.run(JUnit3TestReference.java:128)
at org.eclipse.jdt.internal.junit.runner.TestExecutio n.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRu nner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRu nner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRu nner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRu nner.main(RemoteTestRunner.java:196)

[rasky]

Right, that would probably be caused by the TempEntryRenamingStrategy (a property on ContextSourceTransactionManager). When you do an unbind inside a transaction the entry is not actually removed from the tree - it's just temporarily renamed and then when the transaction commits the entry is finally removed. This is because we need to be able to restore the state in case of a rollback, and there is no way to be sure that we got all information about an entry when (some attributes may be invisible). There are different strategies for how this should work.

By default the entries are just renamed in the same location - the least significant part of the DN will be appended with a _TEMP suffix. This will prevent the recursive delete to work, since the context will not be empty. Now, using DifferentSubtreeTempEntryRenamingStrategy you should be able to make it work, since that strategy temporarily moves each deleted entry to a different part of the LDAP tree, allowing the recursive operation to proceed as expected.

[andrawu]

you are right!
I have succeed! thank you!!!