Microsoft Web UI

Microsoft has so many web technologies to do the same Web UI AJAX thingy. It does not even funny. Here is the (not exhaustive) list :

• ASP.NET/AJAX
• SliverLight
• Volta
  
• ASP.NET/MVC (a programming model that not related to always related AJAX)
• Visual Web GUI
• ...

Sometimes it is a tough decision to make, especially they are still new and you have to overcome some quirks that are not very well-documented. I used the ASP.NET/AJAX in my most recent project. It turned out that in order to write a AJAX control extender you have to learn a whole framework/library in a completely different language (JavaScript). What a nightmare to maintain the code.

Is object assignment statement thread safe?

It really depends on the type of the assignment.

" The CLR guarantees that for types which are no bigger than the size of a native integer, if the memory is properly aligned (as it is by default - if you specify an explicit layout, that could change the alignment), reads and writes are atomic. In other words, if one thread is changing a properly aligned int variable's value from 0 to 5 and another thread is reading the variable's value, it will only ever see 0 or 5 - never 1 or 4, for instance. For a long, however, on a 32-bit machine, if one thread is changing the value from 0 to 0x0123456789abcdef, there's no guarantee that another thread won't see the value as 0x0123456700000000 or 0x0000000089abcdef. You'd have to be unlucky - but writing thread-safe code is all about taking luck out of the equation."

From link

It does not mention object reference assignment. However the size of object reference is always equal to the native integer which means on 32-bit machine the reference size should be 32 bits and on 64-bit machine the reference size should always be 64 bits, therefore it is thread safe.

Best practice for database version

I was always curious about how other people implement the database versioning in their software development process. Today I tumbled across the following article about best practice in database versioning.

The way I am doing it is quite strange forward and involves 2 steps.

1. Create base-line database.
2. Create and maintain a single change script file which will be checked  into source control.
   

Apparently it works well for us. The difference between the method mentioned in the article and my approach are (A) whether we create multiple files to maintain the changes in the source control (B)whether to create a separated table to maintain the current schema version. Everything else works the same way, including branching and merging.

Point A has no semantic difference.

For point B, it is not necessary because when you apply the script which has a version number in the source control (I am using SubVersion which will generate a unique repository-wide incremental number each time you make change(s) to the source repository and our build number is tied to this number), and therefore you know what is the database schema version after the script applies. If customer reports a problem with build 213, I know exactly what the database schema should be and all the source code that associated with this build.

Session for ASP.NET

I ran across  this article about some hints and tips about session state server in production environment. It is not programming related but I think as a ASP.NET programmer should be aware of it if the site is high-traffic site that uses web farm. It also provides some links to cache server product. I think it is quite useful.