Thomas, Good point. If my understanding of this problem is clear, deadlocks are prone to occur in data models that define classes that are "contained" by other classes and, also, that can act as "master" or top-level "containers" themselves. I can understand how, in this case, two threads could end up waiting on the other to release the lock they need. But, in a data model where "master" classes do not also exist as "contained" classes, it would seem that deadlocks of this nature would not occur. Would you agree?
Note that I am not attempting to rationalize the use of this solution, only attempting to understand the scope of this problem. Thanks, Vince -----Original Message----- From: Thomas Yip [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 3:42 PM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] Purging caches Thank you very much Vince, Several people had proposed cache clearing in the last two years, however, none of them would really work. (To be very honest, I think there are more issues generated than it would solves, by adhoc attempts) While I am impressed to see that you even take care of the related object's cache, I must let you know that your code is very prone to deadlock. Generally, you should never call any method that would acquire any more monitors inside a syn block, unless you can sure about the order of acquiring the monitors. Consider the following code: synchronized( locks ) { entry.leave(); if ( entry.isDisposable() ) { // ----- Modified by Vince Adamo ----- if ( entry.isExpired() ) { // all contained objects now need to be // explicitly expired. molder.expireCache(entry); cache.expire(oid); } else cache.put( oid, entry ); // ----- End modifications ----- } } ClassMolder method will acquire other monitors in "unpredictable" order, it mean it might be deadlocked. And, "locks" is quite coarse-grain, it mean it is very likely to deadlock, except in single thread environment. Thomas -----Original Message----- >From: Adamo, Vince [mailto:[EMAIL PROTECTED]] >Sent: Thursday, April 18, 2002 11:23 AM >To: [EMAIL PROTECTED] >Subject: Re: [castor-dev] Purging caches > >Kevin, > >I really appreciate the feedback, thanks. I have, since posting my original >modifications, integrated my stand-alone unit test case into the JDO test >framework. In addition, because of that effort, I have made some minor >modifications to the original code. My plan now is to upgrade to 0.9.3.12, >merge in the code you posted, merge in the minor fixes I need to make, and >re-run the unit test. If all goes well I will repost the files, including >the unit test class. > >Vince > >-----Original Message----- >From: Smith, Kevin [mailto:[EMAIL PROTECTED]] >Sent: Thursday, April 18, 2002 11:09 AM >To: [EMAIL PROTECTED] >Subject: Re: [castor-dev] Purging caches > > >It appears that the virus scanning software installed on the office mail >servers may have stripped my zip file from my previous mail. If so, you can >also get the zip here: > >http://www.electricanvil.com/castor > >-----Original Message----- >From: Smith, Kevin [mailto:[EMAIL PROTECTED]] >Sent: Thursday, April 18, 2002 11:38 AM >To: [EMAIL PROTECTED] >Subject: [castor-dev] Purging caches > > >A while back there was a thread on the list discussing how to selectively >purge Castor's caches. Using the patch that Vince Adamo first submitted >(thanks Vince!), I think I have something that works against the later >Castor stuff. > >In the attached zip is the contents of Vince's patch along with my one >change. This patch is against Castor 0.9.3.12. Apologies for the excriable >formatting. My installation of VisualAge seems to go its own way when >exporting code :( > >Caveat: I've only tested this with time-limited caching. I expect that it >should work regardless of the cache type, but I haven't had a chance to do >any in-depth testing. > >--Kevin > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
