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. 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.
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. john mcnally Kelvin Tan wrote: > > That's a good point actually, since this problem only arises in the presence > of a cache, the cache should fix it. > > Still, if I recall, Scarab's GlobalCacheService doesn't do that sort of > thing...:-) > > Kelvin > > ----- Original Message ----- > From: Iourovitski, Ilia <[EMAIL PROTECTED]> > To: Turbine Users List <[EMAIL PROTECTED]> > Sent: Tuesday, December 11, 2001 9:58 AM > Subject: RE: [Torque] Failed testcase > > They shouldn't be thread-safe to be used in cache. The cache should > implement read-write locks, so only one thread can access them. Database > will serialize changes anyway. > > Ilia > > -----Original Message----- > From: Kelvin Tan [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 10, 2001 5:48 PM > To: Turbine Users List > Subject: Re: [Torque] Failed testcase > > ----- Original Message ----- > From: John McNally <[EMAIL PROTECTED]> > To: Turbine Users List <[EMAIL PROTECTED]> > Sent: Tuesday, December 11, 2001 12:51 AM > Subject: Re: [Torque] Failed testcase > > > Torque objects as currently written will not work well in a cache. > The > > objects are not thread-safe. there are cases where the objects are > > generally used in as read-only or you are only using the simple bean > > properties that map the db columns, that you may be able to get away > > with caching them, but in general it cannot be done. > > > > john mcnally > > > > That's interesting, coz I haven't seen this mentioned in the archives or > documentation before. Shouldn't this be mentioned somewhere in the > documentation, or is it assumed that if something is not explicitly > labelled > as thread-safe, then it isn't? > > Looking at Scarab code, it seems like the Attribute object, at least, is > cached by TurbineGlobalCacheService. Is there anything special you're > doing > to support that then, or is it assumed that this won't be an issue (no > pun > intended!) given the expected load of Scarab? > > Do you see Torque going down the thread-safe path then? My understanding > of > Torque is still pretty rudimentary, so if I intend to work on it, can > you > point me in the right direction? > > Kelvin > > -- > 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]> > > -- > 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]>
