Question

here is some insert code

gkInfo.data.ToList()
           .ForEach(p => p.hour.ToList()
                .ForEach(r => r.block.ToList()
                        .ForEach(q =>
                        {
                            var v = new VarValues();
                            v.dt = DateTime.Parse(p.target_date + " " + (r.value - 1).ToString() + ":00:00");
                            v.id_objecttype = config.stations.Where(i => i.text == q.station_name).Single().id_objecttype;
                            v.id_object = q.bnum.ToString();
                            v.id_param = config.stations.Where(i => i.text == q.station_name).Single().id_param;
                            v.pl_lev = 3;
                            v.source = 0;
                            v.value = q.block_state;
                            v.version = version;
                            v.description = q.change_type;
                            m53500context1.VarValues.InsertOnSubmit(v);
                        }

        )));


            m53500context1.SubmitChanges();

and this code, locks table.
can i avoid it? or its impossible?

Answer 1

Although I don’t know all the details regarding your issue the patterns seems very familiar. Often times you need to do a big update in the database, but at the same time you still need the database be available, so for example if there is a web site that is working off the dataset, it does not time-out while update operations in progress.

Sometimes update operations can be regular exports from another database, sometimes, calculating some caches, not unlike the example you have provided.

If you need your update be transactional (i.e. all or nothing), there is no real way around the lock. While the update is underway the table is locked. If you don’t need transaction, then you can try and break up you update to smaller batches. SubmitChanges, wrap all the changes in a single transaction, so you gonna need to use several SubmitChanges, so each individual transaction is fast and thus not locking the table for long.

If being transactional is a requirement, you can do you inserts in a staging area, i.e. not in the same table that other processes read from. When the insert is finished you figure out the way, to swap the areas. This could complicated by the fact that there maybe updates into this table that you haven’t accounted for, but I do not know if this is true in your case.

In the worst case you will need to have some application logic, that knows that update is in progress and while it’s happening it reads the data from an alternate location. Of course you will have to provide this alternate location (a copy) to read from.

There is no hard and fast answer, but there a few things (above) that you can try. Also feel free to tell more about your specific task / requirements.