Why OleDbCommand objects are not thread safe? 
Author Message
 Why OleDbCommand objects are not thread safe?

I was wondering why the OleDbCommand objects are not
thread safe? This is what the API mentions:

"Any public static (Shared in Visual Basic) members of
this type are safe for multithreaded operations. Any
instance members are not guaranteed to be thread safe."

I see how a static variable of this type can be made
thread safe.
The confusion is why it doesn't guarantee thread safety
when we create multiple instances of this type? I checked
the API to see if there were any static variables in the
class, which can potentially cause some contention issues
in instantiated objects, but I was not able to find any.
The only thing which I can think of is probably the
command Object caches certain data in the write process
and other threads might not be able to see it real time.
But, I don't know if my assumption is right or not. Any
insight would be helpful.



Tue, 07 Jun 2005 02:43:51 GMT  
 Why OleDbCommand objects are not thread safe?
You can have 2 threads using the same object. All you would have to do is
spin off a new thread that does something with your oledbcommand object, at
the same time you do. So both the original thread and the new thread may try
to execute a query on the object. This would clearly cause problems, and is
not thread safe. I can't think of a why this object could be made thread
safe.


Quote:
> I was wondering why the OleDbCommand objects are not
> thread safe? This is what the API mentions:

> "Any public static (Shared in Visual Basic) members of
> this type are safe for multithreaded operations. Any
> instance members are not guaranteed to be thread safe."

> I see how a static variable of this type can be made
> thread safe.
> The confusion is why it doesn't guarantee thread safety
> when we create multiple instances of this type? I checked
> the API to see if there were any static variables in the
> class, which can potentially cause some contention issues
> in instantiated objects, but I was not able to find any.
> The only thing which I can think of is probably the
> command Object caches certain data in the write process
> and other threads might not be able to see it real time.
> But, I don't know if my assumption is right or not. Any
> insight would be helpful.



Tue, 07 Jun 2005 02:53:43 GMT  
 Why OleDbCommand objects are not thread safe?
It's referring to the problem of more than one thread accessing a single
instance at the same time. Next to no non-trivial code is thread safe from
that perspective. They could make everything thread safe by locking
everywhere, but this would slow things down, and lead to deadlock problems.

--
Nick Holmes
Coyote Software, GmbH.


Quote:
> I was wondering why the OleDbCommand objects are not
> thread safe? This is what the API mentions:

> "Any public static (Shared in Visual Basic) members of
> this type are safe for multithreaded operations. Any
> instance members are not guaranteed to be thread safe."

> I see how a static variable of this type can be made
> thread safe.
> The confusion is why it doesn't guarantee thread safety
> when we create multiple instances of this type? I checked
> the API to see if there were any static variables in the
> class, which can potentially cause some contention issues
> in instantiated objects, but I was not able to find any.
> The only thing which I can think of is probably the
> command Object caches certain data in the write process
> and other threads might not be able to see it real time.
> But, I don't know if my assumption is right or not. Any
> insight would be helpful.



Tue, 07 Jun 2005 02:48:40 GMT  
 Why OleDbCommand objects are not thread safe?
Thanks for the reply Marina. I understand these issues but my question
was why the .NET framework doesn't guarantee thread safety of the
OleDbCommand objects? Why independent objects of the OleDbCommand type
are not thread safe?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!



Tue, 07 Jun 2005 03:08:38 GMT  
 Why OleDbCommand objects are not thread safe?
Thanks for the quick reply, Nick. But, I was trying to understand the
design decision and philosophy behind making the static instance thread
safe and not object instances. I'm just curious as to why the objects of
type OleDbCommand are not thread safe?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!



Tue, 07 Jun 2005 03:08:37 GMT  
 Why OleDbCommand objects are not thread safe?
Both Nick and I explained why that is.

Again, it is basically impossible (or at least incredibly difficult if not
impossible) to guarantee thread safety when the SAME INSTANCE can be used by
more then one thread to do something like retrieve data at the same time -
which one wins, what happens? If this could have been done trivially, it
would have been.


Quote:
> Thanks for the reply Marina. I understand these issues but my question
> was why the .NET framework doesn't guarantee thread safety of the
> OleDbCommand objects? Why independent objects of the OleDbCommand type
> are not thread safe?

> *** Sent via Developersdex http://www.developersdex.com ***
> Don't just participate in USENET...get rewarded for it!



Tue, 07 Jun 2005 03:17:16 GMT  
 Why OleDbCommand objects are not thread safe?
Basically, the OleDbCommand has a certain amount of state internal to it,
which changes as calls are made on it. The object would appear to be
volatile if two threads used it simultaneously, even if the individual calls
where thread safe. So the designers just don't both doing anything, and rely
on you to serialize access to it in a meaningful way.

--
Nick Holmes
Coyote Software, GmbH.


Quote:
> Thanks for the quick reply, Nick. But, I was trying to understand the
> design decision and philosophy behind making the static instance thread
> safe and not object instances. I'm just curious as to why the objects of
> type OleDbCommand are not thread safe?

> *** Sent via Developersdex http://www.developersdex.com ***
> Don't just participate in USENET...get rewarded for it!



Tue, 07 Jun 2005 03:13:30 GMT  
 Why OleDbCommand objects are not thread safe?
On Thu, 19 Dec 2002 14:17:16 -0500, "Marina"

Quote:

>Both Nick and I explained why that is.

>Again, it is basically impossible (or at least incredibly difficult if not
>impossible) to guarantee thread safety when the SAME INSTANCE can be used by
>more then one thread to do something like retrieve data at the same time -
>which one wins, what happens? If this could have been done trivially, it
>would have been.

The docs seem to say that for any class, a static member is thread
safe??? I may have slightly miss read that, but.

would I be correct in assuming that any static member can only be
executed buy one thread at a time... there only exists one section of
code in memory for a static? so that a call on a static can only work
on one thread at a time, somehow the runtime, framework, or something
else locks on entry to the static and releases on exit???

Does this mean that as long as the static  does not access an instance
object that may be referenced by another static, or instance object
then only one thread will work on it at any given point in time..

eg: (pseudo code, and assumes that AObject is accessable from within
the Class.static somehow)

MyClass.static {
  AObject.Dosomething

Quote:
}

Is OK for multiple threads, but...

MyClass.static {
 AObject.Dosomething

Quote:
}

MyClass.static2 {
 AObject.Dosomething

Quote:
}

is not ok (two seperate statics)... and :

MyClass.static {
 AObject.Dosomething

Quote:
}

SecondClass.static {
 AObject.Dosomething

Quote:
}

is not ok (two classes/seperate statics)

because AObject has multiple possible access points, each of which
could be in its own thread??

Infact AObject could also be accessed from other objects, not just
statics... in which case would I be correct in assuming that AObject
should be handling the locking, not the classes that are accessing
it??

--
Jonathan Wilson,
AS/400 Business Consultant/Programmer. (UK)
+44 (0)115 9192648
C# .Net trainee.
Currently available for work, resume available on request,
More than happy to take a permanent trainee C# development position.



Tue, 07 Jun 2005 06:45:27 GMT  
 Why OleDbCommand objects are not thread safe?

Quote:
>Thanks for the reply Marina. I understand these issues but my question
>was why the .NET framework doesn't guarantee thread safety of the
>OleDbCommand objects?
> Why independent objects of the OleDbCommand type
>are not thread safe?

Independent objects are thread safe.
The "same instance" of the object is not thread safe.

Hope this helps.

Thank you,
Bobby Mattappally
Microsoft VC++/C# Team

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

Quote:


>X-Newsreader: AspNNTP 1.50 (ActionJackson.com)
>Subject: Re: Why OleDbCommand objects are not thread safe?

>Thanks for the reply Marina. I understand these issues but my question
>was why the .NET framework doesn't guarantee thread safety of the
>OleDbCommand objects? Why independent objects of the OleDbCommand type
>are not thread safe?

>*** Sent via Developersdex http://www.developersdex.com ***
>Don't just participate in USENET...get rewarded for it!



Wed, 08 Jun 2005 08:05:32 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Why is function static singleton not thread-safe?

2. ATL Objects Are Not Thread-safe?

3. Call to local static object constructor not thread-safe

4. Why isn't ICollectionOnSTLImpl thread-safe?

5. When to keep an object thread-safe?

6. Is MFC 4.2 thread safe in object level?

7. Is ATL's CComPtr not thread safe ?!!

8. Apartment thread is not safe ?

9. _endthread() Safe to call if not in thread?

10. sprintf not thread safe

11. CRichEditCtrl - Not thread safe?

12. Is NetShareEnum NOT thread-safe

 

 
Powered by phpBB® Forum Software