Just a follow-up post. Is anyone using Torque with a (database) cache? Basically what I'd like to do is cache the business objects returned by Torque to reduce the hits on the database, which seems to be pretty tough because the business objects communicate directly with the database via the Peer classes. Similarly, as the objects returned aren't thread-safe, this might also be an issue.
It seems like a cache within Torque itself is in the pipeline (i think!), but what about communicating with an application-level cache, much like the global cache in Fulcrum. Regards, Kelvin ----- Original Message ----- From: Kelvin Tan <[EMAIL PROTECTED]> To: Turbine Users List <[EMAIL PROTECTED]> Sent: Tuesday, December 11, 2001 11:39 AM Subject: Re: [Torque] Failed testcase > > I think it would be better to design the objects to only maintain > > references to other objects by pk, so that when the objects are > > requested their status of whether there is a read or write lock can be > > determined, or the objects themselves should contain this information. > > hmmmm...but that wouldn't be very object-oriented would it? Objects are also > coupled to the persistence mechanism. > > OTOH, if a proxy object is used, that'd be pretty interesting. > > > But I have not put enough thought into it. If the objects can be left > > as is and any MT issues taken care of by the cache that would be great, > > but I have my doubts. > > I doubt it too. At least from how I'd approach it, I'll have to rely on the > honesty of clients to explicitly acquire the write-lock when writing, and to > not modify the object when requesting read-only. > > > > > In scarab with Attributes and a few other objects that are being cached, > > they are mostly used in a read-only manner. The code that makes changes > > to them has to be implemented with thread safety in mind. Hopefully, > > this is maintained through all the code changes that occur while > > building and maintaining the app, but it is not a good solution. > > Agreed. The contract should be made more explicit. > > Kelvin > > > > > john mcnally > > > > > > -- > 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]>
