on 2/3/02 7:51 PM, "Aaron Smuts" <[EMAIL PROTECTED]> wrote:
> Back to the point. I could have the managers use Torque for data access > and the managers could still handle the caching, but it might be nice to > have torque handle some of this on its own. The complexity of handling > group dependencies on items matching certain parameters might be a mess, > but for item level stuff it would be nice. Sort of like Javlin (sp?) > and an appserver all in one. > > Where might caching fit into torque? > > What about JCS as a turbine service? > > Aaron Just some thoughts... I need caching in Torque as well...I suspect that all of the doSelect(), doUpdate(), doDelete() methods in the Peers would need to be made intelligent about caching. We would also want the field level methods (the get/setters) and the save() method in the BO to help with invaliding and updating the cache. You also would need to add some sort of dependency tracking into the objects which are related to each other through joins in the database so that when one changes, the other changes as well. This part can turn into a logistical nightmare if you have several levels of joins. Of course all of this would need to be able to be turned off at a moments notice as well...however, if it is done right, it should be unnoticeable when caching is turned on because the invalidation/updating will be so efficient and work so well, that you won't even know that an object came from the database or from the cache... -jon -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
