Announcement Announcement Module
Collapse
No announcement yet.
contextsource and a datasource (HotSwappableTargetSource) Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • contextsource and a datasource (HotSwappableTargetSource)

    I was wondering if it is possible using the HotSwappableTargetSource together with a datasource (oracle) and a contextSource or is this only used for two or more datasources ?

    The problem is I have to write to the ldap repository via Spring's LdapTemplate and to an oracle db at the same time. Or is there a better solution to solve this ?

    Thanks for any advice

    Kristof

  • #2
    I'm not sure if I'm understanding you correctly. You'll need to use a ContextSource together with your LdapTemplate instance (for LDAP access) and a DataSource with your JdbcTemplate instance (for oracle access).

    If I misunderstood, please don't hesitate to ask again.

    Comment


    • #3
      Yes Rasky thanks for your reply that's correct, I have a contextSource(ldap) and a Datasource(oracle).

      The question I have is how can I switch from one to the other so I can use 1 DAO for both, is a HotSwappableTargetSource a valid option or is there a better solution ?

      And another issue I'm having concerns a transactionmanager.
      I've seen that in the latest release there's a ContextSourceTransactionManager and a ContextSourceAndDataSourceTransactionManager but it mentions that they don't support XA transactions so I wonder if it is a good idea to use this.
      So I'm still thinking of dealing with the Ldap transactions myself and use a jtaTransactionManger for the rest.

      Thanks

      Comment


      • #4
        I can't see how the HotSwappableTargetSource would help you here. It's for completely different stuff. You should probably use two different DAO classes, one for LDAP access, with an LdapTemplate instance and one for JDBC access, with a JdbcTemplate instance. You should then have a service class that does all the high-level logic, calling to each respective DAO for the details.

        When it comes to Spring LDAP transaction support it is true that it doesn't have any true XA support. But do you really access several different SQL DataSources in the same transaction (in addition to the one oracle datasource)? That would be the only case that you'd have any need for Jta transactions, as you'll never get any real XA support towards the LDAP database regardless of whether you implement the LDAP transactions yourself or not.

        Comment


        • #5
          Hello,

          You should then have a service class that does all the high-level logic, calling to each respective DAO for the details
          that's just my problem, I have at the moment a service layer which has 1 DAO injected.
          I thought I'd had to work with one DAO and in the DAO itself switch to the other datasource.
          So are you saying that it would be better if I inject in the service two different DAO's, one for ldap and one for database handling ?


          And I only access 1 SQL DataSource, so you are saying I should use Jta transactions there and take care of the ldap transactions myself ?

          Thanks for helping me out...

          Comment


          • #6
            Originally posted by dencamel View Post
            So are you saying that it would be better if I inject in the service two different DAO's, one for ldap and one for database handling ?
            That's exactly the point of the service layer, gluing business logic together by integrating different lower-level service providers, e.g. DAO objects. In the simplest of cases you just have one DAO and you forward the calls from the service layer to the DAO, but there are many cases in which your service class will need multiple collaborators to perform its work. This is precisely such a case: you know that you need to update data in a SQL database and an LDAP database; you let the service class take care of the higher-level logic, delegating to each respective DAO for the different data sources.

            When it comes to transactions, if you only have one SQL datasource there is no point whatsoever to use JTA transactions; these are only needed when transactions need to be synchronized between different XA capable datasources. In your case you want to synchronize transactions between an SQL datasource and one LDAP datasource, which is not possible to do in full extent. However, using the ContextSourceAndDataSourceTransactionManager you can get some extent of synchronization. It won't be true XA, but the transactions will be synchronized - when you choose to rollback the current transaction (automatically by configuration or programmatically) both transactions will be rolled back. Also, if something goes wrong during the commit of the LDAP part of the operation, the SQL part will automatically be rolled back. It won't work the other way around however, once the LDAP part of the transaction has been committed it can't be rolled back, so if something goes wrong during the commit of the SQL part of the transaction you will still be stuck with inconsistent data.

            To summarize, I'd recommend you to use the ContextSourceAndDataSourceTransactionManager. It will do what you want and work for the vast majority of cases.

            Comment


            • #7
              Thanks again for your information, it really helps me out.
              I have just some last remarks :

              This is precisely such a case: you know that you need to update data in a SQL database and an LDAP database; you let the service class take care of the higher-level logic, delegating to each respective DAO for the different data sources.
              So I could also create some sort of a bean factory (DaoFactoryBean) that lets you switch between the DAO implementations, this would mean the service layer will have a reference to that factory.

              So working with only 1 DAO and using a HotSwappableTargetSource to swap between the datasource themselves is not considered as a good idea ?

              so if something goes wrong during the commit of the SQL part of the transaction you will still be stuck with inconsistent data.
              That is what's bothering me now.
              The application is working at the moment with only an ldap backend where I'm taking care of the transactions myself.
              So if some sort of exception happens during the binding process I catch it and delete the created account (if any) and rethrow a "DataException".
              Now I have to see how I can synchronize all this with the database part, I'll certainly have a look at the ContextSourceAndDataSourceTransactionManager, too bad it only works in one direction.... well you can't have it all I guess ;-)

              Thanks again for your feedback !

              Comment


              • #8
                So I could also create some sort of a bean factory (DaoFactoryBean) that lets you switch between the DAO implementations, this would mean the service layer will have a reference to that factory.
                FactoryBean is a powerful concept if you need to dynamically switch between various implementations and still refer to them like "just another bean". However, if you already know which implementations you need and they can be created as plain beans, there is no need to involve factory beans. It just complicates things.

                If I were you, I would have wired up the two DAO beans with their JdbcTemplate and LdapTemplate, injected them into the service bean, perform whatever logic necessary with those DAOs, wired up a ContextSourceAndDataSourceTransactionManager, and configured the proxy stuff to add transaction to my service methods.

                So working with only 1 DAO and using a HotSwappableTargetSource to swap between the datasource themselves is not considered as a good idea ?
                No.

                The application is working at the moment with only an ldap backend where I'm taking care of the transactions myself.
                So if some sort of exception happens during the binding process I catch it and delete the created account (if any) and rethrow a "DataException".
                This is exactly what the transaction support in Spring LDAP 1.2-RC1 provides out-of-the-box.

                Comment


                • #9
                  Originally posted by dencamel View Post
                  I'll certainly have a look at the ContextSourceAndDataSourceTransactionManager, too bad it only works in one direction.... well you can't have it all I guess ;-)
                  The thing is that it does work both ways. The only instance in which you would be in trouble is when something goes wrong during the actual commit of the database part of the transaction.

                  Comment


                  • #10
                    Hello Ulsa and Rasky

                    If I were you, I would have wired up the two DAO beans with their JdbcTemplate and LdapTemplate, injected them into the service bean, perform whatever logic necessary with those DAOs, wired up a ContextSourceAndDataSourceTransactionManager, and configured the proxy stuff to add transaction to my service methods.
                    Ok in my case it will not be the JdbcTemplate but hibernate's SessionFactory.

                    This is exactly what the transaction support in Spring LDAP 1.2-RC1 provides out-of-the-box.
                    Yes but when I did the implementation last year I worked with LdapTemplate-1.0.2 so there wasn't any transaction handling at that time.
                    So I will have to upgrade..

                    Btw say you add the transaction management declaratively as you mention, will this have any impact on the code if you still want to programmatically catch a specific Exception like for example "DataIntegrityViolationException".
                    The reason I'm asking this is that in some cases for the application this isn't an exception ; for example say you create an ldap entry and it already exists you can handle this by catching the above mentioned exception and send a message to the user.

                    I'm still a little in the dark concering the problem with the synchronization but when I start with the implementation I will read it more thoroughly.

                    Thanks again.

                    Comment

                    Working...
                    X