> > If multiple front-end Turbine servers implement DB caching in front of > a single back-end DB server, won't the Turbine machines get out of > sync? > Each cache is unaware of what the other one has or is doing.
Data integrity is the biggest problem in caching. There are a variety of ways to minimize the severity of the issue. Event propagation, centralized data access, and expiration are the major techniques. JCS is a distributed caching system that can be configured in various modes. The two primary distributed caching patterns are lateral and centralized remote caching. In lateral caching, like the JCache that Oracle is developing, the local caches communicate with each other, propagating updates, puts, and removes. In a centralized remote cache, a centralized server manages data integrity. JCS can be configured to run in either mode. The lateral system still needs some work, but the remote store is efficient and stable. The cache is pluggable. You can add auxiliary caches of any variety. Those included are disk cache, rmi cache, http lateral, tcp lateral, and udp lateral. Each area can benefit from more work. You might want to plug in a hsql database disk cache or a jms lateral . . . One benefit of a remote store is that it insures a higher accuracy in delivery order, but this is always an issue. I'm working on a variety of failover and clustering strategies for the remote store. Failover and primary remote recovery is working. I need to add some options to dump local caches on remote recovery and the like. I'm also working on a system, where the remote cache will try alternate means of communicating remove request in case it loses a local. The locals can also employ this technique if they loose remote connectivity. This should be fairly simple to implement using the http lateral auxiliary. You can also set expiration times to insure that your data can only get so out of synch, even in catastrophic scenarios. One nice feature for making the invalidation of out of date data easier is partial-key or hierarchical removal. If you informally group data using ":" as a separator, you can remove related data by calling remove with a colon at the end of the key. > Seems the caching should be done by the DB machine so the views it > presents are consistent to front-end boxes. This is the solution proposed by most application servers, but it can't match the performance of a combined local and remote caching system. It is easier to get right though, until you move into clustering. You certainly want to try and access data from a source that handles data manipulation, so you can keep the caching in a manageable spot. More later. I have to go get a tree. Aaron -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
