Shared dataset & SyncLock

  • Thread starter Thread starter MichalR
  • Start date Start date
M

MichalR

Welcome

I have some solution and I wonder if it's proper (I haven't an
opportunity to test it in production env. yet).

There is a single typed dataset instance, stored in asp.net Cache. It is
referenced by about 30 users. There are two tables - Table1 and Table2
with the master-detail relation (Table1.id - Table2.Table1id). Now I
want to delete Table1 record and all child records form Table2 without
using dataset's cascade delete feature (ds is a typed dataset reference,
dataAdapterT1, dataAdapterT2 are the SqlDataAdapters, I also removed all
try/catch and SqlTransaction related code for simplicity):

.....
dim ds as dsMain=Cache("dsMain")
.....

Sub DeleteFromTable1ByID(id as integer)
SyncLock ds
dim t1r as ds.Table1Row=ds.FindByid(id)
dim t2r as ds.Table2Row
For Each t2r In t1r.GetTable2Rows()
t2r.Delete()
Next
t1r.Delete()

dataAdapterT1.Update(ds)
dataAdapterT2.Update(ds)
End SynckLock
End Sub


The question is if such usage of SyncLock is proper and will not hurt
the application performace too much. I wonder if SyncLock have sense
here at all and if maybe I should place "End SynckLock" before firing
dataadapters' update methods?

Any opionon are welcome.
Thanks,
Michal
 
MichalR said:
Welcome

I have some solution and I wonder if it's proper (I haven't an
opportunity to test it in production env. yet).

There is a single typed dataset instance, stored in asp.net Cache. It is
referenced by about 30 users. There are two tables - Table1 and Table2
with the master-detail relation (Table1.id - Table2.Table1id). Now I
want to delete Table1 record and all child records form Table2 without
using dataset's cascade delete feature (ds is a typed dataset reference,
dataAdapterT1, dataAdapterT2 are the SqlDataAdapters, I also removed all
try/catch and SqlTransaction related code for simplicity):

....
dim ds as dsMain=Cache("dsMain")
....

Sub DeleteFromTable1ByID(id as integer)
SyncLock ds
dim t1r as ds.Table1Row=ds.FindByid(id)
dim t2r as ds.Table2Row
For Each t2r In t1r.GetTable2Rows()
t2r.Delete()
Next
t1r.Delete()

dataAdapterT1.Update(ds)
dataAdapterT2.Update(ds)
End SynckLock
End Sub


The question is if such usage of SyncLock is proper and will not hurt
the application performace too much. I wonder if SyncLock have sense
here at all and if maybe I should place "End SynckLock" before firing
dataadapters' update methods?
Click to expand...

SyncLock is fine here, and you want to maintain the lock while doing the db
updatas, but it won't have any effect unless you also synclock the object
whenever you try to read from it. As to the performance, it depends on how
often you read/write to the dataset.

David

David
 
David said:
SyncLock is fine here, and you want to maintain the lock while doing the db
updatas, but it won't have any effect unless you also synclock the object
whenever you try to read from it. As to the performance, it depends on how
often you read/write to the dataset.

David

David
Click to expand...
That's very interesting for me. Does it means that I should use for example:
....
SyncLock ds
datagrid1.databind()
End SyncLock
.....
(datagrid has a databinding to the ds)

I think it will disallow concurrent _reads_ from the dataset (which
should be allowed, shouldn't it?). I wonder how to lock dataset only
during delete batch.
 
MichalR said:
David Browne wrote:
Click to expand...
.. . .
That's very interesting for me. Does it means that I should use for example:
...
SyncLock ds
datagrid1.databind()
End SyncLock
....
(datagrid has a databinding to the ds)

I think it will disallow concurrent _reads_ from the dataset (which
should be allowed, shouldn't it?). I wonder how to lock dataset only
during delete batch.
Click to expand...

Yes it would. The object's monitor is a symetric lock.
Take a look at the
System.Threading.ReaderWriterLock

which supports concurrent read locks and exclusive write locks.

Or . . ..

In your writer thread populate an entirely new dataset, apply the changes to
it, update the database, and then switch it with the cached dataset. It's
possible that reader threads will briefly read stale data, but it's fast and
easy.

David
 
David Browne wrote:
.. . .
Yes it would. The object's monitor is a symetric lock.
Take a look at the
System.Threading.ReaderWriterLock

which supports concurrent read locks and exclusive write locks.

Or . . ..

In your writer thread populate an entirely new dataset, apply the changes to
it, update the database, and then switch it with the cached dataset. It's
possible that reader threads will briefly read stale data, but it's fast and
easy.

David
Click to expand...

Great thanks for pointing me here! I see there are many System.Threading
classes wchich can bring a new quality in sharing objects.

best regards,
Michal
 
Back
Top