Thanks, Vince, fo rtaking the time to explain this in more detail. Based on what you said, I cannot see a reason as to why changes would be required.
I'd be very eager to test this, but cannot really afford to check out non-production ready code at the moment. Is you patch actually applicable to Castor 0.9.3.9, or woul dit require us to move to the latest disted release before trying to apply it ? Werner "Adamo, Vince" wrote: > Werner, > > 'contained' means all objects related to the parent object through a 1:1 or > 1:m relationship. In effect the code walks the relationship graph expiring > each contained, or related, object. > > The implementation to clear all cached objects of a given type uses a coarse > level locking mechanism that would lead to deadlock issues if all related > type's were cleared in a single operation. While it would probably be > possible to implement a solution that released this coarse lock after each > type's cache is cleared, I opted to keep the code more simple and require > the user to know what the related object type's are when calling the API. > If this places an undue burden on the caller of the API I would consider > re-thinking the implementation. > > I hope this helps. > > Vince > > -----Original Message----- > From: Werner Guttmann [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 09, 2002 5:15 AM > To: [EMAIL PROTECTED] > Subject: Re: [castor-dev] Flushing the object cache > > Vince, > > thank you very much for below description. Can I ask some random question ? > > "Adamo, Vince" wrote: > > > I added a new method, expireCache, to the Database and DatabaseImpl > classes. > > The following is from the javadoc generated from this modification: > > > > "public void expireCache(java.lang.Class[] type, > > java.lang.Object[] identity) > > throws PersistenceException > > > > Expire objects from the cache. Objects expired from the cache will be read > > from persistent storage, as opposed to being read from the performance > > cache, during subsequent load/query operations. Objects may be expired > from > > the cache individually, using explicit type/identity pairs in the argument > > list, or whole classes of objects may be expired by specifying a class > type > > without a corresponding entry in the identity array. > > > > When objects are expired from the cache individually, by identity, objects > > contained within a "master" object, for example objects maintained in a > > one-to-many relationship, will automatically be expired from the cache, > > without the need to explicitly identify them. > > Can you please refine 'contained' in this context. DOes this apply to all > relationship types ? Iow, 1:1 and 1:M. > > > This does not apply when expiring objects by type. > > Interesting ? What's the difference here that expiration of contained > objects > would not work when expiring by type only ? Just being curious ? Is this the > final functionality, or something still in development ? > > > Each type, both container and contained objects > > need to be specified." > > > > Vince > > > > -----Original Message----- > > From: Martin, Margaret [mailto:[EMAIL PROTECTED]] > > Sent: Monday, October 07, 2002 11:55 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [castor-dev] Flushing the object cache > > > > I believe that it supports flushing specific objects, classes of objects, > > and the entire cache - but perhaps Vince could weigh in wiht a more > > definitive answer - > > > > Margaret > > > > -----Original Message----- > > From: Werner Guttmann [mailto:[EMAIL PROTECTED]] > > Sent: Monday, October 07, 2002 11:42 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [castor-dev] Flushing the object cache > > > > At what level would this support flushing ? Flush the whole cache ? Or > just > > specific object instances ? > > > > Werner > > > > "Martin, Margaret" wrote: > > > > > Boris, > > > Take a look at the cache code that Vince Adamo posted some time back - > it > > > should adress this exact problem. As far as I know, the code has not > been > > > committed to the archives yet, but it is in use for several > > implementations, > > > so it is getting a workout - > > > > > > Hope this helps - > > > Margaret > > > > > > -----Original Message----- > > > From: Boris Klug [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, October 07, 2002 8:35 AM > > > To: [EMAIL PROTECTED] > > > Subject: [castor-dev] Flushing the object cache > > > > > > Hello! > > > > > > I am still fighting with the timestamp/caching issue, now will try to > > store > > > the timestamp in the db when I have time to do it. > > > > > > Another question would be: Is there a way to flush the object cache so > > > Castor > > > has to read in all (cached) objects when they are are used again? > > > > > > I store information about user/group/rights in the db and when the > rights > > > for > > > one users are changed by the administrator, I want to have a menu item > > > "Reread priviledges" for connected users. Now you have to way until the > > > (time-limited) cache will expire. > > > > > > Thank you for your help! > > > > > > -- > > > Dipl. Inform. Boris Klug, control IT GmbH, Germany > > > > > > ----------------------------------------------------------- > > > 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 > > > > ----------------------------------------------------------- > > 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
