How Synclock and Cache Work Together

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
PutTableInCache(dt)

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.

Thanks!
LVL 2
codequestAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

naveenkohliCommented:
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..

gettable()
{
   DataTable dt = null;
   lock(myLock)
   {
      dt = cache.table;
   }
   return dt;
}

settable(dt)
{
  lock(mylock)
  {
     cache,table = dt;
  }
}
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
codequestAuthor Commented:
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.




0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
ASP.NET

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.