You would lose quite bit of benefits of caching if you have to implement the cache on your db server. Databases already have tuning to help with repetitive queries, at least I would think they would. You gain not having to make the request to the database, but since we are talking about separated servlet and db machines, you are still going to have to make the request to the cache if it lives on the db machine. You also now have a jvm (assuming the cache is in java) running on the db server, which eliminates some more benefit from separating the db and servlet container. I see very little benefit to such a cache.
john mcnally Chris Shenton wrote: > > Jason van Zyl <[EMAIL PROTECTED]> writes: > > > I now have Aaron Smut's caching code which I will add to 'stratum' which > > will be the repository for all the common code used in turbine and code that > > is currently in velocity that was originally taken from turbine. Over the > > holidays I will get stratum up on the apache box. The caching package kicks > > some serious ass. > > 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. > Seems the caching should be done by the DB machine so the views it > presents are consistent to front-end boxes. > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
