Announcement Announcement Module
No announcement yet.
Ldap Tx Mgmt Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Ldap Tx Mgmt

    Hi all,

    I'm really fond of Spring and I've been tinkering with the LDAP api over the last few days.

    Almost everything worked as expected and how is clearly explained in the reference pdf. Good stuff indeed! I had really a great time!

    Unfortunately, I have some difficulties only with the Compensating Transaction Management, certainly a mistake of mine.

    There follows a brief excerpt from my applicationContext.xml:

    <prop key="create">PROPAGATION_REQUIRES_NEW</prop>
    <prop key="modify">PROPAGATION_SUPPORTS</prop>
    <prop key="delete">PROPAGATION_SUPPORTS</prop>

    I created 3 methods for the ordinary CRUD operations.

    I tried to apply the settings specified in chapter 4 but it didn't seem to work. What happens is that if a Runtime Exception is thrown while the methods are being executed (for instance in modify as soon as un item has been modified, no rollback action is taken.

    What's more if I suspend the debug execution during the execution of methods which should be in a transaction context, I can clearly see that no recording/preparation rollback activity is actually ongoing, that's to say no 'cn=Joe Doe_temp...' entry appears.

    I'm using Sun Directory Server 5.2. I'd be really gratefull if someone could give me some hint and some working code + settings involving ldap tx management would be greatly appreciated!

    Thanks so much,

  • #2
    Excellent, wonderful to get some feedback on the transaction stuff. Unfortunately, the provided information is insufficient to give a really good guess as to what's going wrong.

    One guess would be that you're not using the ContextAwareContextSourceProxy properly. Another guess would be some mismatch in the TransactionProxyFactoryBean configuration.

    Please post your configuration (oh, and btw, please use the 'code' tags - it makes the code so much easier to read), and I'll try to make a more educated guess.


    • #3
      Some details

      Hi Rasky,

      it's so kind of you to have addressed my question!

      Please find in attach the applicationContext.xml and the PersonDaoImpl bean I have been working on.

      In my tests I tried to simulate the transactional behaviour of the bean of class PersonDaoImpl calling the following code:

      public void testTransaction(){
      try {
      } catch (Throwable e) {
      assertNotNull(toTest.getPersonNamesByLastName("foo "));

      Furthemore in the body of the delete method I throw a RuntimeException in order to set off a rollback action.

      Unfortunately, while debugging the code I can see that no compensative transaction measure is actually taken and at the end of the catch I would expect the item created in the 'create' method weren't there any more.

      Hope the info provided is enough..Besides, I was wondering whether I should use some tx manager (jotm or the like), but the fact the management is compenstive made me think that was not the case...Am I wrong?

      Last but not the least Couldn't you give me any of your working code+setting to clarify the correct working of this nice Spring-Ldap feature?

      Thanks again for your advice and for working on such a powerful and impressive framework!



      • #4
        The thing is that setting the transaction proxy on the dao object creates/commits transactions for each new call on that object, so that your call to create, update and delete will each take place in a separate transaction. In order to have them execute in the same transaction you'll need to set the transaction proxy on the class that executes the sequence of operations, e.g. a service object.

        This means that the stuff is probably working - the create and update transactions were successful, but the transaction in which the delete operation was executed was rolled back (causing the entry to still be in place afterwards).

        Does that make sense?


        • #5

          Hi Rasky,

          it worked! The only strange thing is I cannot see the temporary entry through the LDAP browser while the 'transactional method' execution is stopped after one issues the modify request and is about to throw the RuntimeException.

          Anyway it is definitely working as the previous value is restored...

          Thanks so much indeed


          • #6
            Ah, that's easily explained. The modifyAttributes operation doesn't create a temporary entry - it really makes the modification to the original entry and stores compensating modifications internally for rollback.


            • #7
              temp entry

              Hi Rasky,

              you're absolutely right. On attempting to delete an entry, a foo_temp entry does appear!

              Thanks! Really well done!