Jason van Zyl <[EMAIL PROTECTED]> writes: > On 12/14/01 11:24 AM, "Chris Shenton" <[EMAIL PROTECTED]> wrote: > >> Seems the caching should be done by the DB machine so the views it >> presents are consistent to front-end boxes.
That would be re-inventing EJBs, and IMHO is not the way to go. Any RDBMS/OS implementation worth its salt can do this caching to some extent anyhow. The main expense is the object construction/destruction (all that pushing, popping, and processing gives both the heap and your CPU a work out), and for that you need in memory caching. > I think it can be done in a distributed fashion, but Aaron has a lot more > experience in this area than I so maybe he can answer your question with > some degree of authority. For SourceCast, we've found that it makes the most sense to maintain a LRU-based cache on each application server in the cluster, and perform cache invalidation across the network (preferably using a reliable multicast based implementation of a JMS or JMS-act-alike system). This allows each app server to have an up to date cache of business objects, and optmizes for the common case (read-only access to your data and business rules). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
