3 Replies Latest reply on May 10, 2009 4:01 PM by Brendan Meutzner

    Connect to different database on demand?

      This is a conceptual question. Can I have a client connect to a different data service (database) on demand? Can requests from one computer connect to "Database A" and requests from another computer connect to "Database B"? I'd like to have one application deployed to the application server but clients connect to a different DB depending on the client.
        • 1. Re: Connect to different database on demand?
          Brendan Meutzner

          Brian,

           

          Did you find a solution on this?  I've posted the same question recently with no answer so far, so thought I'd check to see if you'd figured things out.

           

           

          Thanks,

           

          Brendan

          • 2. Re: Connect to different database on demand?
            Steve L Walker Level 5

            Which service(s) do you plan to use to connect to the data source?

             

            More importantly, how are you going to identify a client to determine which data source they should access?

             

            Steve

            • 3. Re: Connect to different database on demand?
              Brendan Meutzner Level 1

              Tom Jordahl provided the answer on this for me.  Here's the solution:

               

              1) Prior to implementing this solution, it's important to realize that because LCDS manages the data, switching datasources dynamically could potentially cause issues if there is overlap between identifiers on the records you are retrieving.  In my case, I'm using GUID fields as primary key and identifiers in my destinations, so this is not a problem.  However, for example, if you were to use an incrementing integer for the identifier, then you could feasibly have LCDS managing a record, which would match identifiers with a record if you switched datasources on the fly.

               

              2) I'm using ColdFusion as my middle-tier layer, but this could be applied to any form by accessing the flex.messaging.FlexContext class within your solution of choice.

               

              3) The solution involves extracting the ID value of Flex client which makes calls against your Destination.  Grab the identifier by calling FlexContext.getFlexClient().getId() to get a unique key for the "session".  I use the term "session" loosely, as it's really just representative of the particular swf instance which has been loaded with your Flex Application.  However, the ID doesn't change and persists across all calls you make against your destinations. 

               

              4) On application load, make a call to your CF layer which gets the ID, and sets it to the Application scope of the CF server as follows:

               

                   <cffunction name="set" access="remote">

                        <cfargument name="datasource" type="string" required="yes" default="">

                        <cfset var clientID="">

                        <cfscript>

                             clientID = CreateObject('java', 'flex.messaging.FlexContext').getFlexClient().getId();

                             APPLICATION[clientID] = arguments.datasource;

                        </cfscript>

                 </cffunction>

               

              The function above receives a unique string which I want to be my datasource of choice.  You could call this "set" function again anytime to reset the Application variable for this "session".

               

              5) The only other thing to do, is now access this Application variable for each datasource.

               

                   datasource="#APPLICATION[CreateObject('java', 'flex.messaging.FlexContext').getFlexClient().getId()]#"

               

              6) The last consideration is that each connection that is made via Flex will be setting a new variable in the Application scope on the Coldfusion server.  This is a pretty minor concern for me, and I'll just run a schedule to clear the Application scope once a day, but if you have a high volume of users, a better solution would have to be found.