lock(??)
-
I've got a Singleton instance of my class(A) that contains the functions for filling (passed on)datasets using 1 of 2 resident data adapters: the default adapater(A1) (for executing queries that will not be updated back to the database), and one for specially created and monitored for the query(A2) (that can be used to update data back to database). This all operates using delegates and call backs to the calling class'(B-Z) method. The database is hosted on the internet so, i need the delegation so the ui threads are not waiting for the data to return from the server. What i'm not sure about is how the lock() will affect my program flow and what will happen when i lock the singleton instance A. At this stage i'm only locking the A1 adapter instance. I want to lock the whole instance of A so that other data requests don't interfere with the current data request. Will it lock(A) the lock the instance in use by other classes in other threads or should i rather use a single line queue for data filling/updateing? I would appreciate if some can enlighen me.
-
I've got a Singleton instance of my class(A) that contains the functions for filling (passed on)datasets using 1 of 2 resident data adapters: the default adapater(A1) (for executing queries that will not be updated back to the database), and one for specially created and monitored for the query(A2) (that can be used to update data back to database). This all operates using delegates and call backs to the calling class'(B-Z) method. The database is hosted on the internet so, i need the delegation so the ui threads are not waiting for the data to return from the server. What i'm not sure about is how the lock() will affect my program flow and what will happen when i lock the singleton instance A. At this stage i'm only locking the A1 adapter instance. I want to lock the whole instance of A so that other data requests don't interfere with the current data request. Will it lock(A) the lock the instance in use by other classes in other threads or should i rather use a single line queue for data filling/updateing? I would appreciate if some can enlighen me.
If you use lock(A), the A object will only be accessible for the thread that locked it. Any other thread that wants to access the object will wait until it gets unlocked. There are different cursor types that decides what happens to a database result when data in tables changes. If you use a static cursor (adOpenStatic), the result is a static copy from the table, and won't be affected by changes in the table. If you can make the adapter use a static cursor, you don't have to use locking to protect the data in the result. --- b { font-weight: normal; }
-
If you use lock(A), the A object will only be accessible for the thread that locked it. Any other thread that wants to access the object will wait until it gets unlocked. There are different cursor types that decides what happens to a database result when data in tables changes. If you use a static cursor (adOpenStatic), the result is a static copy from the table, and won't be affected by changes in the table. If you can make the adapter use a static cursor, you don't have to use locking to protect the data in the result. --- b { font-weight: normal; }
Guffa wrote:
make the adapter use a static cursor, you don't have to use locking to protect the data in the result.
the reason is not for data protection - its to minimize adapter creation and optimize adapter use during runtime.
Guffa wrote:
Any other thread that wants to access the object will wait until it gets unlocked.
does this happen 'automaticlly' or should it controlled by the .NET Monitor class?
-
Guffa wrote:
make the adapter use a static cursor, you don't have to use locking to protect the data in the result.
the reason is not for data protection - its to minimize adapter creation and optimize adapter use during runtime.
Guffa wrote:
Any other thread that wants to access the object will wait until it gets unlocked.
does this happen 'automaticlly' or should it controlled by the .NET Monitor class?
A correction to my previous statement: The lock statement doesn't lock the object per se, it only prevents the code in the lock statement (or any other lock statement using the same object) to be entered by another thread. The object is only used as an identifier, so it doesn't matter what object you use if you only have one lock statement. The lock statement calls System.Threading.Enter, which uses the Monitor class. A lock statement is the convenient form of:
try {
System.Threading.Ender(theObject);
... lotsa code
} finally {
System.Threading.Exit(theObject);
}--- b { font-weight: normal; }