Hmmn. We should reset create time on clone. If this isn't happening we should create a bug and some unit tests. I'll get to it after the remote cache shutdown issue.
Yes, setting create time sounds a bit funny. It doesn't sound like create time should be public, but now that people might be using it, it would be hard to change. . . . I'll look into. Cheers, Aaron --- Thomas Vandahl <[EMAIL PROTECTED]> wrote: > Hi there, > > I'm working in the Torque and Turbine projects. I'm > trying to improve > some of the caching functions there (they are based > on JCS, for those > who don't know). For a better understanding of JCS' > internals I wrote an > implementation of the Turbine GlobalCacheService > which uses JCS. There I > stumbled across a problem that I would like to ask > you about. > > In GlobalCacheService you create CachedObjects which > have a certain > lifetime. The life time can be defined for each > object individually. I > thought that setting ElementAttributes per object > would be a good way to > implement this. *However* when I request a copy of > the > ElementAttributes from my region, the create time is > not updated, so > that - as time passes - I happen to put objects into > the cache which are > expired immediately. > > I found that casting to the implementation > ElementAttributes (not the > interface) gives me access to the members of the > object (Why are these > public, anyway?), so that I can update the > creationTime. But I'm feeling > uncomfortable with this solution. How is the kosher > way to solve this? > > Bye, Thomas. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
