471,317 Members | 2,578 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,317 software developers and data experts.

Locking Reference Objects

I have a DataSet that is cached deep down in a business layer object.
Higher up, there's a merge being performed on that object and it very
occassionaly throws a NullReferenceException deep down in the merge
code. I suspect that the DataSet is being edited during the merge by
another thread or its going out of scope (i.e. expiring).

The question is whether I can/should lock that reference object. Would
it help?

For example:

public SomeMethod() {
DataSet moreData = SomeObject.GetNonCachedData();
DataSet blah = SomeObject.GetCachedDataSet();
lock(blah) {
moreData.Merge(blah);
}
}

In this case 'blah' is a local object so it's not a threading issue per
se. I just think that another thread is affecting the cache and since
the DataSet is a reference object, it's causing this method to blow up.
What I'm really looking for is the best way to keep that reference
object from being edited during the merge. Is using that lock going to
help me?

Dec 21 '05 #1
7 1365
Schroeder,

Is moreData a reference that is returned that is shared? If so, then
you should probably lock on this before you make changes to it.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Schroeder" <kw******@paloma.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...
I have a DataSet that is cached deep down in a business layer object.
Higher up, there's a merge being performed on that object and it very
occassionaly throws a NullReferenceException deep down in the merge
code. I suspect that the DataSet is being edited during the merge by
another thread or its going out of scope (i.e. expiring).

The question is whether I can/should lock that reference object. Would
it help?

For example:

public SomeMethod() {
DataSet moreData = SomeObject.GetNonCachedData();
DataSet blah = SomeObject.GetCachedDataSet();
lock(blah) {
moreData.Merge(blah);
}
}

In this case 'blah' is a local object so it's not a threading issue per
se. I just think that another thread is affecting the cache and since
the DataSet is a reference object, it's causing this method to blow up.
What I'm really looking for is the best way to keep that reference
object from being edited during the merge. Is using that lock going to
help me?

Dec 21 '05 #2
Schroeder <kw******@paloma.com> wrote:
I have a DataSet that is cached deep down in a business layer object.
Higher up, there's a merge being performed on that object and it very
occassionaly throws a NullReferenceException deep down in the merge
code. I suspect that the DataSet is being edited during the merge by
another thread or its going out of scope (i.e. expiring).

The question is whether I can/should lock that reference object. Would
it help?
Very unlikely. One thread locking on something doesn't stop another
thread from doing something unless the second thread *also* tries to
lock on the same thing.
For example:

public SomeMethod() {
DataSet moreData = SomeObject.GetNonCachedData();
DataSet blah = SomeObject.GetCachedDataSet();
lock(blah) {
moreData.Merge(blah);
}
}

In this case 'blah' is a local object so it's not a threading issue per
se. I just think that another thread is affecting the cache and since
the DataSet is a reference object, it's causing this method to blow up.
What I'm really looking for is the best way to keep that reference
object from being edited during the merge. Is using that lock going to
help me?


Is this DataSet bound to any UI controls? If so, you shouldn't let any
thread other than the UI thread update it. Might that be part of the
problem?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 21 '05 #3
moreData is not a reference to any shared data. It is only used by the
method in question.

Dec 21 '05 #4
Well, which ones are shared then?
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Schroeder" <kw******@paloma.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...
moreData is not a reference to any shared data. It is only used by the
method in question.

Dec 21 '05 #5
Nicholas Paldino [.NET/C# MVP] <mv*@spam.guard.caspershouse.com> wrote:
Is moreData a reference that is returned that is shared? If so, then
you should probably lock on this before you make changes to it.


That won't do any good unless anything else that uses it *also* locks
on it first.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 21 '05 #6
I "refactored' the code to make it more clear.

public DataSet SomeMethod() {
DataSet nonSharedDataSet = SomeObject.GetNonCachedData(); // not
shared data...unique to this method
DataSet sharedDataSet = SomeObject.GetCachedDataSet(); // shared
data
lock(sharedDataSet) {
nonSharedDataSet.Merge(sharedDataSet);
}

return nonSharedDataSet
}

To answer Jon's question... yes, the results are being bound to a
control. The problem is that since it's working off of a shared cache
I can't really prevent other threads from modifying it. Or, at the
very least, I can't be sure that the cache isn't going to get blown
away by the cache engine due to age or memory usage.

Dec 21 '05 #7
Schroeder <kw******@paloma.com> wrote:
I "refactored' the code to make it more clear.

public DataSet SomeMethod() {
DataSet nonSharedDataSet = SomeObject.GetNonCachedData(); // not
shared data...unique to this method
DataSet sharedDataSet = SomeObject.GetCachedDataSet(); // shared
data
lock(sharedDataSet) {
nonSharedDataSet.Merge(sharedDataSet);
}

return nonSharedDataSet
}

To answer Jon's question... yes, the results are being bound to a
control. The problem is that since it's working off of a shared cache
I can't really prevent other threads from modifying it. Or, at the
very least, I can't be sure that the cache isn't going to get blown
away by the cache engine due to age or memory usage.


The cache being blown away isn't a problem, but you *must not* modify a
DataSet when it's bound to controls, unless you're "in" the UI thread.
The events fired would mean UI code getting executed in the wrong
thread.

This may or may not be what's causing your problem, but it's a
potentially serious design issue for you.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 21 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Michael Chermside | last post: by
2 posts views Thread by spammy | last post: by
reply views Thread by Timo | last post: by
10 posts views Thread by McFly Racing | last post: by
14 posts views Thread by Laura T. | last post: by
6 posts views Thread by Akula | last post: by
reply views Thread by =?UTF-8?B?TmlscyBPbGl2ZXIgS3LDtmdlcg==?= | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.