This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
It appears that if I just new a DefaultCache into a CacheBroker that just making changes to the entity and calling SaveChanges() will not update the cache. I need to explicitly call Cache.Update(entity) in order to update the cached data. Is this correct or am I missing some configuration/etc that will automatically update the DefaultCache implementation with changed data. b r a d |
|
|
No, the cache should update automatically -- you shouldn't need to call Update manually. Are you in a transaction? The cache is updated only when the transaction is committed. |
|
|
We are using a TransactionScope, but Complete is called. Is there something else we should be using or some kind of additional event handling we should be using? |
|
|
OK, it appears to be an issue with UnitOfWork lifetime and the Transaction update mechanism. We are using DTOs and were doing something like this.
using (var uow = _ctx.CreateUnitOfWork()) { var sub = uow.FindById<Subscriber
Mapper.Map<ISubscriberDto, SubscriberDto
>(updateDto).CopyTo(sub);
uow.SaveChanges();
return
sub.AsDto();
}
But in order to update the cache, it appears that the UnitOfWork must survive until the TransactionScope is Complete(d). So we need to lose the using statement. My only question then is I can wrap the TransactionScope around multiple SaveChanges calls and reuse the Singleton UnitOfWork as much as I want and shouldn't have any problems(leaks, etc), correct? |
|
|
Hmm, TransactionScope.Complete appears to be pretty much a no-op. All the actual committal appears to happen in Dispose. At least in my tests, if I call Complete but not Dispose, the transaction is NOT committed and the database is not updated. The TransactionCompleted event -- which is what we rely on to update the cache -- is therefore not signalled until TransactionScope.Dispose is called. So you must Dispose the TransactionScope as well as Complete-ing it. I have to admit I find this surprising -- but this is the way it seems to be! Yes, you are right that the UOW needs to survive until the transaction commits. And yes, it is safe to perform multiple SaveChanges calls within a single TransactionScope. (And while you keep the same UOW around it will give you the same entities from the identity map, so the deferred update to the L2 cache won't be a problem.) |
|