Comments on: What’s the deal with LightSpeed caching?

By: John-Daniel Trask

John-Daniel Trask — Tue, 07 Jun 2011 21:40:01 +0000

It won’t be cached by default. The first level caching is done at the UnitOfWork scope. If you add a cache provider (second level cache) to the LightSpeed context then they will be cached outside of your unit of work scope (so outside of your “//OpenTransfers is an entity” line.

So add a second level cache and you’re good to go Mike.

By: Mike Nacey

Mike Nacey — Tue, 07 Jun 2011 21:33:05 +0000

To be clear, something like:

using (var uow = _ctx.CreateUnitOfWork())
{
var transfers = uow.OpenTransfers;
} // OpenTransfers is an entity. So this loads them all.

is never going to be cached? I routinely use dictionary tables that could be cached for hours.

By: Aaron Murrell

Aaron Murrell — Thu, 25 Feb 2010 16:24:06 +0000

How does the 2nd level caching infratructure deal with Unit of Work issues that could result from the UnitOfWork references (and other entity references) being propagated across Entities used in different UnitOfWork contexts?

For instance, I have a unit of work for editing a Student entity. I pull a Category entity (reference data) from cache and associate it with the Student entity. The UnitOfWork from my Student Entity gets propagated to my Category entity and the bidirectional object reference from Category to Student (and back) gets set. When my form / unit of work for editing that student goes out of scope, what prevents the cached Category from keeping references around for the UnitOfWork that was used and the student object reference that ideally should be garbage collected?

By: John-Daniel Trask

John-Daniel Trask — Sun, 06 Dec 2009 01:30:36 +0000

Hi Dan,

About 3/4 of the way through the post I mentioned that we currently ship with a Memcached second level cache.

Due to the pluggable nature of the second level cache it shouldn’t be too difficult to plug in a Velocity provider as well.

I hope that helps.

By: Dan Barratt

Dan Barratt — Sun, 06 Dec 2009 00:51:33 +0000

Have you thought about allowing Velocity or Memcached for the second level cache provider? Being able to cache entities across a server farm would really raise the bar.

By: John-Daniel Trask

John-Daniel Trask — Mon, 09 Nov 2009 20:58:12 +0000

Hi MiddleTommy,

New objects would be in the first level cache, not in the second level cache. Of course, they won’t match any results returned until they’re saved so it’s not “caching” so much as just where they live before they get saved or thrown away :-)

If I understand your second question correctly you mean “if I add a comment to a contribution, don’t save it, then fetch all comments, do I get all the comments including the new one that is not saved yet?” then no – you do not. This is for several reasons – complexity of translating DB queries into in-memory queries, unexpected results for most users, etc.

I hope that helps answer your questions MiddleTommy – let me know if I’ve missed the point of your second question or if you’d like more clarification :-)

By: MiddleTommy

MiddleTommy — Mon, 09 Nov 2009 14:01:04 +0000

Is the cache used for new items(items not yet saved to the database)?

And when a query is run are new items returned if they match the query results?

By: John-Daniel Trask

John-Daniel Trask — Sun, 08 Nov 2009 22:22:22 +0000

Hi Richard,

No, not currently, but we will look into this post 3.0 as it would be a nice enhancement.

Thanks for your feedback!

By: Richard Weaver

Richard Weaver — Sun, 08 Nov 2009 22:01:54 +0000

Is query caching (rather than just FindById) in the pipeline for 3.0?