What may be a better test is actually to discard the object, and then re-get it, and see if it is the same object.
Just looking through how isCached is used, you would need to rationaliseKey() it, to make sure it is in the standard format... there may be some case sensitivity issues and Java data types that may be of issue. Looking through the code of discard(), I'm wondering how this is possible... there has to be almost something else at play here. Basically discard() works like this: gets the class and key from the object tells the cache to discard the class and key the cache looks up the SoftReference for that class and key That SoftReference is then cleared, so there is no reference to the object at all in the cache. Subsequent calls to get / have check to see if there is a SoftReference that refers to a CFC, and only if it exists, and if it's not null, does it return true. I'm wondering if maybe there is something in the process that is reloading the object maybe? Through some sort of lazy load? Mark On Thu, Aug 12, 2010 at 9:37 AM, Mick Hutchinson <hutchinso...@gmail.com>wrote: > Hi Mark, > > Looking through the code for transfer one would expect objects that > have been discarded not to exist in the cache. However, I ran a > simple > unit test overnight and it proved otherwise. As suggested I made the > Transfer.isCached() method public. The test involved randomly loading > 1000 parent objects and their child collections. Once everything was > loaded I looped back through those objects discarding each parent as > well as each child. The final iteration simply called the isCached() > method and, if it found the object in cache, wrote a line to the > console. Of the 1000 parent objects and their several thousand child > objects there were 25 hits on the cache when there should have been > zero. This would suggest to me something is amiss. > > Thoughts? > > Mick > > On Aug 11, 4:08 pm, Mark Mandel <mark.man...@gmail.com> wrote: > > Movinghttp:// > docs.transfer-orm.com/html/transferapi/transfer/com/Transfer.h...()<http://docs.transfer-orm.com/html/transferapi/transfer/com/Transfer.h...%28%29> > > > > From packaged to public should do the trick for the situation you > describe. > > > > If an object has been discard()'d, then it will be listed as not as being > in > > the cache, as the SoftReference has been cleared at that point. > > > > Let me know how that goes for you, and I'll commit the fix to SVN. > > > > Interesting problem though - I totally see the issue. > > > > Mark > > > > On Wed, Aug 11, 2010 at 4:00 PM, Mick Hutchinson <hutchinso...@gmail.com > >wrote: > > > > > > > > > > > > > Mark, > > > > > Not even sure this is possible but would there be any way to add > > > methods to an ObjectCache to check if an object has been queued for > > > discarding? We're seeing issues whereby bulk operations performed > > > directly against the database followed by relevant discard calls are > > > not performing ideally. Subsequent calls to a parent object to > > > retrieve a child object are effectively creating dirty reads from > > > cache. It would be of great help to add an optional boolean parameter > > > to the Transfer.getMethod() which, set to true, checks if the object > > > is in cache AND IS NOT in the discard queue. > > > > > Mick. > > > > > -- > > > Before posting questions to the group please read: > > > > >http://groups.google.com/group/transfer-dev/web/how-to-ask-support-qu. > .. > > > > > Try out the new Transfer ORM Custom Google Search: > > >http://www.google.com/cse/home?cx=002375903941309441958:2s7wbd5ocb8 > > > > > You received this message because you are subscribed to the Google > Groups > > > "transfer-dev" group. > > > To post to this group, send email to transfer-dev@googlegroups.com > > > To unsubscribe from this group, send email to > > > transfer-dev+unsubscr...@googlegroups.com<transfer-dev%2bunsubscr...@googlegroups.com> > <transfer-dev%2bunsubscr...@google groups.com> > > > For more options, visit this group at > > >http://groups.google.com/group/transfer-dev?hl=en > > > > -- > > E: mark.man...@gmail.com > > T:http://www.twitter.com/neurotic > > W:www.compoundtheory.com > > > > cf.Objective(ANZ) - Nov 18, 19 - Melbourne Australiahttp:// > www.cfobjective.com.au > > > > Hands-on ColdFusion ORM Trainingwww.ColdFusionOrmTraining.com > > -- > Before posting questions to the group please read: > > http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer > > Try out the new Transfer ORM Custom Google Search: > http://www.google.com/cse/home?cx=002375903941309441958:2s7wbd5ocb8 > > You received this message because you are subscribed to the Google Groups > "transfer-dev" group. > To post to this group, send email to transfer-dev@googlegroups.com > To unsubscribe from this group, send email to > transfer-dev+unsubscr...@googlegroups.com<transfer-dev%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/transfer-dev?hl=en > -- E: mark.man...@gmail.com T: http://www.twitter.com/neurotic W: www.compoundtheory.com cf.Objective(ANZ) - Nov 18, 19 - Melbourne Australia http://www.cfobjective.com.au Hands-on ColdFusion ORM Training www.ColdFusionOrmTraining.com -- Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer Try out the new Transfer ORM Custom Google Search: http://www.google.com/cse/home?cx=002375903941309441958:2s7wbd5ocb8 You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en
