> Should value objects be immutable? I've been thinking about freezing
> them after they are added to the cache. I worry that once and object
is
> in the cache it could be shared between any number of threads, so
> contention becomes an issue. For simplicity one might just create a
new
> value object and replace the old one in the cache with it. Is this how
> you do things or do you have a different strategy?
>
This is interesting. I consider the cache to be simply a reference
store. For examples like this the value object wouldn't be modified,
only used. Outside of the cache, you could implement some sort of value
object freezing by protecting the variables and then killing all the set
methods after it has been cached. I've never had the need to do this.
Generally the cached data will not be changed by the program using it.
> > /**
> > * Stores BookVObj's in database. Clears old items and caches
> new.
> > *
> > */
> > public int storeBookVObj( BookVObj vObj ) {
> >
> > try {
> >
> > // since any cached data is no longer valid, we
should
> > // remove the item from the cache if it an update.
> > if ( vObj.book_id_pk != 0 ) {
> > bookCache.remove( "BookVObj" + vObj.book_id_pk );
> > }
>
> Is this (the removal) necessary? I would think that the put that
follows
> would cause the object to be replaced, and that invalidation would
> propagate to any remote / lateral caches. ( As a nice secondary
effect,
> removing this makes this method exactly the same as the code that
stores
> the object in loadVObj, nice bit of refactoring potential =)
>
I removed it at the top, just in case the put failed. It is unnecessary
yes. It is just a safety measure. You could remove either the put or
the remove. I'd remove the put before the remove. Generally it is good
to have specific caching methods when dealing with more than one region
and related caches.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
