concurrency/lock problem?

  • Thread starter Thread starter Matias Woloski
  • Start date Start date
M

Matias Woloski

I have the following code which is running in every Page_Load of my ASP.Net
app.
It basically will add rows to a table upto MAX_CACHED_ITEMS and then will
flush all the cached items to the database.

Do you foresee any concurrency problem? or any performance problem?

private object lockObject = new object();
private static DataTable myTable; //typed table
private const int MAX_CACHED_ITEMS = 50;

lock(lockObject)
{
if( myTable == null )
{
myTable = MyDal.CreateDataTable();
}
myTable.AddxxxxRow( param1, param2, param3 );
if( myTable.Rows.Count >= MAX_CACHED_ITEMS )
{
try
{
MyDal.MyTable.Update( myTable ); // update the db
MAX_CACHED_ITEMS rows
myTable.Rows.Clear();
}
catch( Exception ex )
{
//handle
}
}
}


Thanks,
Matias
 
Matias Woloski said:
I have the following code which is running in every Page_Load of my ASP.Net
app.
It basically will add rows to a table upto MAX_CACHED_ITEMS and then will
flush all the cached items to the database.

Do you foresee any concurrency problem? or any performance problem?

private object lockObject = new object();
private static DataTable myTable; //typed table
private const int MAX_CACHED_ITEMS = 50;

lock(lockObject)
{
if( myTable == null )
{
myTable = MyDal.CreateDataTable();
}
myTable.AddxxxxRow( param1, param2, param3 );
if( myTable.Rows.Count >= MAX_CACHED_ITEMS )
{
try
{
MyDal.MyTable.Update( myTable ); // update the db
MAX_CACHED_ITEMS rows
myTable.Rows.Clear();
}
catch( Exception ex )
{
//handle
}
}
}


Thanks,
Matias


Statics are the worse enemy of performance/scalability in web applications.
So why do you make your myTable static, make it an instance member and
remove the lock.

Willy.
 
Matias Woloski said:
I have the following code which is running in every Page_Load of my ASP.Net
app.
It basically will add rows to a table upto MAX_CACHED_ITEMS and then will
flush all the cached items to the database.

Do you foresee any concurrency problem? or any performance problem?

Yes - your lock is effectively doing nothing, as you'll have a new
instance of the page for every request.

You need to lock on something shared.
 
sorry, I mistyped the code.

The lock object is static.

private static object lockObject = new object();

Now?
 
Matias Woloski said:
sorry, I mistyped the code.

The lock object is static.

private static object lockObject = new object();

Now?

The question is why do you share the table, I don't see any, but you might
have good reasons to do so, in that case there is nothing else you can do
than synchronize access to it.

Willy.
 
The question is why do you share the table, I don't see any, but you might
have good reasons to do so, in that case there is nothing else you can do
than synchronize access to it.

I could create an instance and save it to the cache.
Now, the difference between having static or cache is just that the cache
will manage expiration, right?

Btw, I need to have a global scoped table because I'm storing Page-View
records in this table, so I want to add rows to that table for any user that
enter in my app. When I reach MAXITEMS I will flush the table to the
database

That make sense?

Thanks,
Matias
 
Matias Woloski said:
I could create an instance and save it to the cache.
Now, the difference between having static or cache is just that the cache
will manage expiration, right?

Btw, I need to have a global scoped table because I'm storing Page-View
records in this table, so I want to add rows to that table for any user
that enter in my app. When I reach MAXITEMS I will flush the table to the
database

That make sense?

Thanks,
Matias

I would add the record to the cache after having updated the Database (note
that you can always use a private cache for the table data if you wan't to
update in batches). That way you reduce the time you are holding a lock to
the time it takes to update the cache.

Willy.
 
Back
Top