Announcement Announcement Module
Collapse
No announcement yet.
Is there an LdapTransactionManager? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Is there an LdapTransactionManager?

    Is there an available TransactionManager that can handle LdapTemplate and JdbcTemplate in the same transaction? I'm using DataSourceTransactionManager and it doesn't rollback any transactions with LdapTemplate (obviously).

    Thanks,

    Matt

  • #2
    The catch is that there's no such thing as transactions in the LDAP world.

    We've been discussing implementing some kind of 'client-side' transaction management implementing a transaction manager and keeping track of modifications on the client side, 'rolling back' in case anything goes wrong (or if the user requests it). I guess it could be useful, even though it wouldn't be transactions as you generally would think of them (server-side that is).

    Whether we'll do that pretty much depends on interest from the community; it's not scheduled for the near future however.

    Comment


    • #3
      So if I understand correctly it is not possible to roll back a transaction because there is no notion of a transaction in the Ldap world ?

      Not even when using a JTA transaction manager like the WebLogicJtaTransactionManager and using the annotations on the business service methods like :
      Code:
      @@DefaultTransactionAttribute(propagationBehaviorName="PROPAGATION_REQUIRED")

      I've tested this with junittests that extend the AbstractTransactionalSpringContextTests and the log states that the entry is rolled back but when I look at the ldap repository this is not the case.

      It even states that it's got the Ldap context (Got Ldap context on server 'ldap://test:1234/dc=be') so doesn't this mean that transaction handling is possible ?
      If it is, why is the entry still visible in the ldap repository ?

      Thanks for any info...

      Kristof

      Code:
      [WebLogicJtaTransactionManager] Using transaction object [org.springframework.transaction.jta.JtaTransactionObject@183268e]
      [WebLogicJtaTransactionManager] Creating new transaction with name [null]
      [WebLogicJtaTransactionManager] Beginning JTA transaction
      [TransactionSynchronizationManager] Initializing transaction synchronization
      [AccountServiceTest] Began transaction: transaction manager [org.springframework.transaction.jta.WebLogicJtaTransactionManager@bbaa16]; defaultRollback true
      [LdapContextSource] Principal: 'uid=test,ou=people,dc=be'
      [LdapContextSource] Got Ldap context on server 'ldap://test:1234/dc=be'
      [WebLogicJtaTransactionManager] Triggering beforeCompletion synchronization
      [WebLogicJtaTransactionManager] Initiating transaction rollback
      [WebLogicJtaTransactionManager] Rolling back JTA transaction
      [WebLogicJtaTransactionManager] Triggering afterCompletion synchronization
      [TransactionSynchronizationManager] Clearing transaction synchronization
      [AccountServiceTest] Rolled back transaction after test execution
      Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.969 sec

      Comment


      • #4
        Once again, transactions don't exist in the LDAP world. It isn't part of the spec, and so the servers don't support it.

        The only way to do this is to handle it manually on the client, keeping track of the changes and putting stuff back the way they were if anything goes wrong. Of course, that wouldn't be transactions as we know it in the database world (e.g. if you lose your connection you'll end up with inconsistent data anyway) but it's the best we can achieve working with LDAP.

        Note that it would be quite possible to have that 'manual' work done automatically and that might be something we would include in Spring LDAP in the future if there's enough demand for it.

        Comment


        • #5
          Demand for LDAP transactions

          Hello, I do believe that there is enough demand for LDAP transactions (even though they are simulated on the client side). It is only that people dealing with LDAP programming do not know about the great active development being achived in this group. My congratulations!!

          Comment

          Working...
          X