Locking Datatable / Data Row

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,

if you have defined a DataSet in the HttpApplicationState which is
shared by all current users ...

what I have to do, to make the Dataset, DataTables and DataRows
thread-safe?

Following my assumptions:

1) If I change a Row:
lock (datarow)
{
datarow["xy"] = value;
}

2) If I add Rows
lock (datatable)
{
datatable.Rows.Add(..)
}

3) If I use the Fill method
lock (datatable)
{
adpt.Fill(datatable);
// what happens with changed or currently locked datarows?
// e.g: process 1 locks row X of datatable A
thread 2 wants to lock datatable A, is process 2 waiting for process 1
to unlock row A

}

4) If I make AcceptChanges to DataTable or DataRow
lock (datatable)
{
datatable.AcceptChanges();
}

5) For datatable.Remove (lock datatable)
6) For datarow.Delete() (lock datarow)
7) For dataset.Tables.Add() (lock dataset)

8) If I do a datatable.select(...) what a have to do to make it
thread-safe?

Is this correct or completly wrong?

in your applicatoin writes on rows can only be done by one user at the
same time, reading should be possible for all users "at the same
time".

Maybe yo have some answers...
 
You might want to always lock the DataTable instance,for all of your
operations with the exception of the Dataset.tables.add

Locking a datatable may not necessarily lock the data in the rows in all
cases, so you can't count on that lock cascading through the object hierarcky
 
I am not locking table always . I need to lock the row .. is it safe for
below senrio

David Jessee said:
You might want to always lock the DataTable instance,for all of your
operations with the exception of the Dataset.tables.add

Locking a datatable may not necessarily lock the data in the rows in all
cases, so you can't count on that lock cascading through the object hierarcky






Prem said:
Hello,

if you have defined a DataSet in the HttpApplicationState which is
shared by all current users ...

what I have to do, to make the Dataset, DataTables and DataRows
thread-safe?

Following my assumptions:

1) If I change a Row:
lock (datarow)
{
datarow["xy"] = value;
}

2) If I add Rows
lock (datatable)
{
datatable.Rows.Add(..)
}

3) If I use the Fill method
lock (datatable)
{
adpt.Fill(datatable);
// what happens with changed or currently locked datarows?
// e.g: process 1 locks row X of datatable A
thread 2 wants to lock datatable A, is process 2 waiting for process 1
to unlock row A

}

4) If I make AcceptChanges to DataTable or DataRow
lock (datatable)
{
datatable.AcceptChanges();
}

5) For datatable.Remove (lock datatable)
6) For datarow.Delete() (lock datarow)
7) For dataset.Tables.Add() (lock dataset)

8) If I do a datatable.select(...) what a have to do to make it
thread-safe?

Is this correct or completly wrong?

in your applicatoin writes on rows can only be done by one user at the
same time, reading should be possible for all users "at the same
time".

Maybe yo have some answers...
Click to expand...
Click to expand...
 
But think about this....you lock a row....while that row is locked, someone
does datatable select.

The Select statement doesn't enumerate through the Rows collection...its
does a binary search on an internal Slect class which looks at the individual
field values, matching the search expression up with the column ordinals.

That being said, the state of the dataset cound be read one way (select)
while the state of the dataset is being modified at the same time by a
different thread (since they're locking on different object instances, but
they're both acting on the same state data. I have no idea what would
happen. If you always lock at the datatable level instead of the row level,
you won't have to find out what happens....at run time....while data is being
modified

Just a thought

Prem said:
I am not locking table always . I need to lock the row .. is it safe for
below senrio

David Jessee said:
You might want to always lock the DataTable instance,for all of your
operations with the exception of the Dataset.tables.add

Locking a datatable may not necessarily lock the data in the rows in all
cases, so you can't count on that lock cascading through the object hierarcky






Prem said:
Hello,

if you have defined a DataSet in the HttpApplicationState which is
shared by all current users ...

what I have to do, to make the Dataset, DataTables and DataRows
thread-safe?

Following my assumptions:

1) If I change a Row:
lock (datarow)
{
datarow["xy"] = value;
}

2) If I add Rows
lock (datatable)
{
datatable.Rows.Add(..)
}

3) If I use the Fill method
lock (datatable)
{
adpt.Fill(datatable);
// what happens with changed or currently locked datarows?
// e.g: process 1 locks row X of datatable A
thread 2 wants to lock datatable A, is process 2 waiting for process 1
to unlock row A

}

4) If I make AcceptChanges to DataTable or DataRow
lock (datatable)
{
datatable.AcceptChanges();
}

5) For datatable.Remove (lock datatable)
6) For datarow.Delete() (lock datarow)
7) For dataset.Tables.Add() (lock dataset)

8) If I do a datatable.select(...) what a have to do to make it
thread-safe?

Is this correct or completly wrong?

in your applicatoin writes on rows can only be done by one user at the
same time, reading should be possible for all users "at the same
time".

Maybe yo have some answers...
Click to expand...
Click to expand...
Click to expand...
 
Back
Top