This is a migrated thread and some comments may be shown as answers.

L2 Cache doubt

6 Answers 122 Views
Getting Started
This is a migrated thread and some comments may be shown as answers.
This question is locked. New answers and comments are not allowed.
Daniel Bichuete
Top achievements
Rank 1
Daniel Bichuete asked on 08 Oct 2010, 01:28 PM

Hi,

 I have one question about OA L2 cache. When using it on a web app, after the object get to the L2 cache when it is gone ? Let's make an assumption....

 Request 1: L2 cache populated with object A

 Request 2: L2 cache populated with object B

 Then if on a third request if I try to access the object A would it be on L2 cache ? We are assuming no process restart... And using IIS 7.

Best regards,

Daniel Bichuete

6 Answers, 1 is accepted

Sort by
0
Accepted
IT-Als
Top achievements
Rank 1
answered on 08 Oct 2010, 02:15 PM
Hi Daniel,

The short answer to your question is "Yes, object A will be in L2 cache".

We have used the L2 cache successfully in a web app and it works great.
As long as you do not have a process restart the L2 cache is alive.

Regards

Henrik
0
Daniel Bichuete
Top achievements
Rank 1
answered on 08 Oct 2010, 04:32 PM

Hi Henrik,

 Thanks for your help ! Just another question, does OA has native support for SqlDependency ?

Best regards,

Daniel Bichuete

0
IT-Als
Top achievements
Rank 1
answered on 11 Oct 2010, 07:46 AM
Hi Daniel,

I don't know if OA has support for the SqlDependency. However, if you use the dependency for caching purposes the L2 cache will do the job as it sits between object scopes / contexts in OA and the physical database. Meaning multiple object scopes / contexts can use the same L2 cache. This is important in multi-threaded apps... for example webapps.

Also. the L2 cache also works in a clustered environment.

Again, if you use SqlDependency for caching purposes, the L2 cache is a perfect replacement. The whole idea with an ORM is to move data access to a higher (and more natural / business like) abstraction layer.

Regards

Henrik
0
Accepted
Petko_I
Telerik team
answered on 13 Oct 2010, 04:44 PM
Hi Daniel and Henrik,

We do not have native support for SqlDependency. However, as Henrik said, the L2 cache is an ideal solution when you want to improve the performance of several threads working with the same persistent objects. I want to give you some links to blog posts regarding the usage of the L2 cache:
OpenAccess ORM Second Level Cache API
Telerik OpenAccess ORM and the Second Level Cache
Using Distributed Cache with Telerik OpenAccess ORM
You should remember to invoke the Evict() method on the cache to remove cached instances which have been updated in the database. As long as you perform the updates with OpenAccess you can always implement some custom logic with events (for example the Tracking events) to notify the appropriate places of your code for the occurrence of modifications.
Do not hesitate to contact us, if you need further information regarding the L2 caching or other topics.


All the best,
Petko_I
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
0
Daniel Bichuete
Top achievements
Rank 1
answered on 17 Oct 2010, 08:48 PM

Hi Petko,

 When using OpenAccess to update data on our database, will other applications that are using L2 cache be notified of this. Asuming they will try to push data again from context, on other words, would OA evict data on L2 cache when it itself update that data on db ?

Best regards,

Daniel Bichuete

0
Petko_I
Telerik team
answered on 20 Oct 2010, 06:17 PM
Hello Daniel Bichuete,

When using the OpenAccess distributed L2 caching, as long as OpenAccess is the only one making updates, suitable events will be fired so that the cache is consistent across all applications. This means that on notification applications automatically evict the modified persistent objects. As described in the blog post I referenced, there is a time window which allows mismatches, i.e. one L2 cache is updated and another one is not. After this time elapses, synchronization takes place. The L1 cache of a scope, however, does not know of this update and you should use the Refresh() method if you keep long living scopes. With short-living scopes – ones that you quickly instantiate to make a modification and then eagerly dispose of the instance – you should normally not worry about inconsistencies. This is because of the fact that when starting a transaction the L1 cache is invalidated.

I believe you can also have a look at the online help article which reveals a bit more on our implementation. Although the topics you see give details about the old scope approach, you can take full benefit of the second level caching with the new domain model.

Feel free to contact us if you need further information.

Kind regards,
Petko_I
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
Tags
Getting Started
Asked by
Daniel Bichuete
Top achievements
Rank 1
Answers by
IT-Als
Top achievements
Rank 1
Daniel Bichuete
Top achievements
Rank 1
Petko_I
Telerik team
Share this question
or