Another Response to More on VDS and Cache
By Mark Wilcox - CTO - Oracle Consulting Security-Oracle on Feb 15, 2009
Ash gave me a heads up that there were some interesting comments on his blog in regards to caching and asked if I would give my thoughts.
Todd Clayton gave an example which I can summarize as follows:
- A company has HQ in Chicago and several branch offices which include customer facing applications
- Each local branch has its own LDAP server for authentication for internal & customers
- There is a proprietary database containing customer entitlement information maintained in Chicago
- A virtual directory will be used to span both the LDAP & to convert entitlements into LDAP accessible data
But then makes a giant leap in assuming the data would need to a persistent cache to be viable for a virtual directory.
Here is how I would answer this - if I was given this as a question from a prospective customer.
First I would say is that just because the database is not local to the branch, does not automatically mean the database needs to be copied to the local branch in order for a virtual directory to make effective use.
For sake of argument - let's assume branch 1 manager says the data link to Chicago is unreliable for persistent network connections, so need to assume that the database will not always be available for persistent connections
To which I would say - "Ok, that's fine. One of the benefits of Oracle is that we have a number of solutions to this type of issue. So let's do some more investigation to see what is the best solution."
Because based on my experience one of three possibilities is really on the table. And each has an optimal solution:
Possibility 1 - Company policy states that the database data cannot be stored in any location except HQ. So while it is possible to query the data - it cannot be stored in the branch
Solution 1 - Use OVD in-memory cache so that data is not stored but in case an application makes repeated queries against the database during a customer log-in, those queries won't make the jump across the WAN. The branch understands that because of company policy sometimes that database will not be available. In those situations - customers might be denied access. But branch understands this is only possible solution unless either data-link is improved or company policy changes.
Possibility 2 - The data can be copied but has never been done because HQ politics have prevented a solution. Additionally the branch(es) needs to run their own database reports against the data (besides using LDAP for authorization). And would prefer to solve that problem as well.
Solution 2 - Use Oracle Times-Ten In-Memory database to make the data available via both the virtual directory and to local SQL-based reporting applications. Benefit of Times-Ten is that its blazingly fast (it's optimized to store data in-memory as primary data-store) and because it's designed to be non-persistent - don't have to worry about local data-storage (in particular if the HQ database is an Oracle DB).
Possibility 3 - The data will only be used for LDAP authorizations. The data-link is truly unreliable and thus the data really need to be stored locally to make this operation viable
Solution 3 - Oracle Virtual Directory is just one component of Oracle Directory Services (which is how its licensed). Oracle Directory Services includes Oracle Internet Directory & Directory Integration Platform. Because this data is mission critical to the branch operations and because it will only be used for LDAP operations and because the data-link is too unreliable for direct connections - DIP can be used to store the data (& keep it updated locally) into OID.
Possibility 4 - The network manager enters the meeting and announces that new private high-speed fiber line is going live next Monday. Thus data connectivity problems will be resolved.
Solution 4 - After go-live discover the SQL queries even with join are resolving faster than the application takes to display their UI. Thus no need to actually cache any data.
- Just because a data-store is remote does not automatically mean "must be copied locally"
- Even if data needs to be copied locally - need to pick a data-store/synchronization solution that meets all of the needs of the customer requirements