jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Smuts <asm...@yahoo.com>
Subject Re: JCS Setup Questions
Date Mon, 07 Mar 2005 04:55:17 GMT

--- Daniel Rosenbaum <drdan321-nospam@yahoo.com>

> I have a side concern specific to using Hibernate
> with
> distributed caching, particularly when caching
> collections.  I
> can best describe my concern with a (somewhat
> contrived)
> example.

Personally, I wouldn't cache inside Hibernate.  I'd
roll my own outside so I have more control.  Caching
is too hard to leave it up to a tool with a generic
solution.  We can move on anyway.

> Say you have a Department object, along with
> Employee objects,
> with a Department.departmentEmployees collection,
> and there are
> 600 employees is a department.  In hibernate, each
> employee
> would have its own object, and the
> Department.departmentEmployees collection would be a
> cache entry
> with the primary keys of all the Employee objects
> that belong to
> that department.  So in all, you have a total of
> 600+1=601
> objects, and therefore 601 items would be put into
> the cache on
> loading this collection, or 601 cache puts.
> Using a lateral cache, this would result in 601
> objects being
> serialized and sent on the network.  This seems an
> expensive
> price for placing this collection in a distributed
> cache.

For soemthing like this.  I assume that employees
don't change often.  This is a startup cost.  The
distribution is so fast, that 600 or even 6,000 is not
very expensive.  You can make things faster if you
control the Serialization, but this is inside of
Hibernate, so I loose that option.  

> Worse, even if only cache invalidate messages would
> be sent on
> new puts, then couldn't the following happen:
> 1) A servlet on Server A loads the collection from
> db.  601
> invalidate messages are sent to server B.
> 2) a short time after, as servlet on Server B also
> loads the
> same collection.  This would also result in getting
> the data
> from the db (since there is no serialization.)  This
> would also
> produce 601 invalidate messages, now to server A.
> 3) a short time after that, Server A loads the same
> collection
> as in (1) again.  It would no longer be in the
> cache, since step
> (2) invalidated it, and would have to go to the
> database again
> to get it!!!

Yep.  Invalidation on put for collecitions can be
nasty.  What we need is a get all on startup feature. 
This works for the remote cache, but not for laterals.

> In other words, you would end up with a cache where
> an entry is
> only valid if that entry is only used on one and
> only one
> server, say if Server A is the only user of those
> entries, but
> if server B ever tries to use it, it would get
> invalidated! 
> This would seem to make the cache have very limited
> use.

If you are not trying to get from other laterals, then
yes, remove on put is useful for data that is most
likely associated with a single user, but could affect
others, in a sticky load balanced situation.  

If you have get enabled, then this isn't a concern.  B
would try to get from A and the endless invalidation
would never have started.  The remote cache is best
for this.

It is better to just put on put for other kinds of
data.  It is not that expensive.

> Another concern I have, say the collection is
> changed on server
> A, which produces 601 messages, and server B starts
> to process
> the messages, but before all the messages are
> processed a
> servlet on server B reads the collection.  If this
> happened
> after only 250 messages are processed, the servlet
> would get a
> collection with 250 new objects and 350 old objects.
>  This would
> be an unacceptable situation where you would have
> inconsistent
> data.  In the employee example, you would have a
> collection with
> 250 employees with up-to-date info but the rest have
> stale info.

If that is what hibernate would do, then yes.  

More later.


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

View raw message