Best Practice question on setting ElementAttributes

[Thomas Vandahl <tv...@apache.org>]

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: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org

Re: Best Practice question on setting ElementAttributes

[Aaron Smuts <as...@yahoo.com>]

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 <tv...@apache.org> 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:
> jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jcs-users-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org