How Synclock and Cache Work Together

Posted on 2006-04-22
Last Modified: 2008-02-01
Suppose I build a datatable, and fill it.
And that I have methods for putting the table in cache (Application Cache or Session cache or "Cache" cache) and getting it out again.

And I put it in cache.  And then I do this:

dim dt as datatable = GetTableFromCache("MyTable")
synclock dt
(do things to dt)
synclock end

What I'm trying to figure out is:
A)  is the dt just a reference to the table, which is actually in cache?
B)  is it necessary to put it back, or have the changes to dt already been made to the table in cache (since dt is just a reference)
C)  is the table in cache safe from any changes by any other thread during this operation, or could a change slip in between the "dim dt" and the "synclock dt".

Any guidance on this would be appreciated.

Question by:codequest
    LVL 23

    Accepted Solution

    1. Yes it is reference to that object on heap. Any changes made to it will get reflected.
    2. You don't have to put it back but it would not hurt to do it. Especially if you are using sliding expiration policy for cach expiration then adding it back will make sure that expiration time has restarted.
    3. Yes, there is a chance somebody can grab the table before you acquire the sync lock. I would suggest to put the accessor methods (get/set) for this table to be encapsulated in their own methods and each method provides synchronized access to the table.

    something like..

       DataTable dt = null;
          dt = cache.table;
       return dt;

         cache,table = dt;
    LVL 2

    Author Comment

    Thanks.  There's a lot to learn about synclock, this was a good start.

    Part of what I'm learning is

    A) recognizing the differences between code blocks (which can include nested calls), code paths (which are strings of blocks, which may cut into a heirarchy of nested calls), and threads (which are actual operations of paths, which then hit blocks.)

    B) understanding that synclocks only lock code blocks, not data elements.  They just keep other threads out of the block, but if there's some other path to get to the data element in (or nested under) the block, then that data element won't be protected by the lock.


    Featured Post

    Why You Should Analyze Threat Actor TTPs

    After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

    Join & Write a Comment

    I have developed many web applications with asp & and to add and use a dropdownlist was always a very simple task, but with the new, setting the value is a bit tricky and its not similar to the old traditional method. So in this a…
    Problem Hi all,    While many today have fast Internet connection, there are many still who do not, or are connecting through devices with a slower connect, so light web pages and fast load times are still popular.    If your ASP.NET page …
    Hi everyone! This is Experts Exchange customer support.  This quick video will show you how to change your primary email address.  If you have any questions, then please Write a Comment below!
    Excel styles will make formatting consistent and let you apply and change formatting faster. In this tutorial, you'll learn how to use Excel's built-in styles, how to modify styles, and how to create your own. You'll also learn how to use your custo…

    734 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    18 Experts available now in Live!

    Get 1:1 Help Now