2005年8月15日
#
很就没发点东西了,我真是太懒了!发点流水账吧:
(1)看看最后一次发随笔的日子是2月7号,那是我撞废第一辆车的前一周,还好我没有受伤。
(2)最近去看了看大家的blog,还是志峰的有情调啊,想学,可是学不来。
(3)七月份休假出去玩了2周,挺爽。
(4)最近嘛,正常情况下还是一周踢一次球,打几次网球,然后周末去远一点的地方玩玩。
(5)一眨眼,夏天友快过去了;不过冬天一样好玩:滑雪!
(6)享受生活每一天!
2005年2月7日
#
ACT --- Application Centre Test is a stress test tool for web application. I met two problems when using this tool last year.
-- If your web application uses Windows Integrated authentication, then you have to do some special things to record your test and make your recorded test scripts work. I don't want to put what you should do, since there are a lot of blogs or articles out there that can help you to solve this issue.
-- The misunderstanding of two test properties: Iteration and the Number of Simultaneous Connections
According to the online help of this tool, you will conclude that the number of simultaneous connections simulates the number of browser connections, which is true. But the term -- iteration really makes trouble, since you tend to think that the iteration stands for the how many times the test will be repeated, which is wrong!
For instance, if you set the Number of Simultaneous Connections to 5 and set Iteration to 5, then I bet you expect the test to simulate 5 browser connections and the recorded scripts will be sent to the web server 5 times. But the truth is the test can only be run for once! In other words, the scripts can only be sent to server once!
So what does Iteration mean? Here Iteration means the number of scripts' copies that will be sent to the web server. And EACH COPY WILL OCCUPY ONE BROWSER CONNECTION IN ORDER TO GET THE SERVER. So for the above example, 5 copies can sent to the server at the same time, since 5 connections are provided. If there are only 1 connection, then the test have be run 5 times and the copies will be sent to the server side one by one.
2004年12月13日
#
Summary: 最近正在准备考SQL Server Programming的证书,同时工作中也遇到一些有关Locking的问题,所以深入的研究了一下这个问题,并将自己的理解总结在这里。没想到我花了4个小时才把这个文章完成,原因是还是有很多东西在写之前没有搞清楚。我写得很匆忙,尤其是到了结尾的时候已经快午夜了,所以就草草收尾了。有什么问题请大家指出来, 谢谢!
Recently, I have been preparing for SQL Server Programming certificate (70-229). Meanwhile, I met some problems about SQL Server performance from work. All these made me dig into the locking architecture of SQL Server. I know there’s something which is not accurate, so please point out if you don’t agree. Thanks a lot!
1 Why locking?
We all learned locking mechanism in Operating System courses in university. Basically, whenever multithreads want to access limited resources (printer, file, database table etc.), locks are applied to the resources to avoid chaos.
In SQL Server, there are different types of limited resources --- Database, Table, Page, Extent, Key, RowID. So SQL Server has its own locking mechanism.
2 What do you do with it?
When you issue a SQL statement, SQL Server dynamically determines where to place locks. For example, locks can be acquired on rows, pages, keys, ranges of keys, indexes, tables or database. But all the things happen behind the scene, you don’t need to take care of it. So you will ask: “Then what do I do with it?”
Your responsibility is to decide what type of locks to be used and the duration of the locking. There are six types of locks --- Shared, Update, Exclusive, Intent, Schema and Bulk Update. Those are the low level types, and you cannot use these types directly. For example, neither can you say I want a Shared lock here, nor can you say I want the locking to work for 3 minutes. What you can do? You can choose a transaction isolation level or you can select a cursor concurrency options. When you do these two things, SQL Server will automatically know when and where to apply locks and how long the locks should work.
So you can take it for granted that locks always come with transactions, cursor or both of them. But you may ask what if I only use a single SELECT statement without transaction? By default, SQL Server runs under Autocommit mode. Under this mode, one SQL statement will be one transaction with default isolation level.
3 Type of locks
There are six types of locks:
Shared locks, Update locks, Exclusive locks, Intent locks, Schema locks, and Bulk Update locks.
Shared Locks
If you use a shared lock when you issue a SELECT, generally, the lock is applied to the rows you selected. But a shared lock still allows other SELECT statements in other transaction to read the data in your selected rows. However, shared lock prohibits other transactions from modifying the data in your rows. The duration of shared lock is as long as the length of the SELECT statement’s life. In other words, Shared locks on a resource are released as soon as the data has been read.
Exclusive Locks
When you want to update data, an Exclusive lock is used and the can guarantee you no other transactions can read or modify data locked within the Exclusive lock.
Update Locks
When you want to update data, the first lock that is used is Update Lock instead of Exclusive lock. Only one transaction can obtain an update lock to a resource at a time. But it’s different from Exclusive lock. An update lock is a hybrid between a shared and an exclusive lock. Update locks are used when a query needs to update one or more records, but until the WHERE clause is complete, the query doesn't know which records it needs to UPDATE. So instead of putting an exclusive lock on every record (which reduces concurrency and your application's performance) it places a shared lock on the requisite records, and only when the WHERE clause is completed, are exclusive locks put on the records that need to be UPDATEDed. The shared locks created by an update lock are held until the WHERE clause is completed running, not immediately released after the row is read, as is normal with a shared lock.
For explanation of other type of locks, please refer to MSDN.
How to use transaction or cursor to determine type of locks and duration of locking
As I said early in this article, locks always come with transactions, cursor or both of them. You can choose a transaction isolation level or you can select a cursor concurrency options to determine type of locks to use and the duration of locking.
Transaction isolation level
There are four isolation levels: READ COMMITED, READ UNCOMMITED, REPEATABLE READ, SERIALIZABLE
READ COMMITED
Specifies that shared locks are held to protect your data from being changed by other transactions. But that’s it, no more than that. Remember I said the duration of shared lock is as long as the length of the SELECT statement’s life. For instance (line number is added for easy reference later):
1) SET TRANSACTION ISOLATION LEVEL READ COMMITED
2) GO
3) BEGIN TRANSACTION
4) SELECT * INTO #tempTable FROM Customers
…. – other operations are omitted here.
5) SELECT * FROM Customers
6) COMMIT TRANSACTION
A shared lock is created for line 4 to lock the result set. Behind the scene, the result set is generated row by row. Imagine the result set contains a million rows, then line 4 will take quite a long time to execute, let’s say 10 seconds. Then the duration of the shared lock for line 4 is 10 seconds. After some other operations between line 4 and line 5, the result set of line 5 is not guaranteed to be same as the result set of line 4, because there’s no lock in between.
READ UNCOMMITED
This is level 0 locking, meaning no locks are issued at all.
REPEATABLE READ
Locks are placed on the data that is used in a query during the whole transaction. Since locks are placed on the selected data, this option can only prevent other transactions from updating the selected data, but it allows other transactions to insert new records of data into the tables you are using.
Here the duration is the whole transaction, but the type of locks are determined by you in the locking hints in the FROM CLAUSE, by default, it’s shared lock.
SERIALIZABLE
Place a range shared lock on the data set (not only on your selected data), preventing other users from updating or inserting rows into the data set until the transaction is complete.
Here the duration is the whole transaction, and the lock type is shared lock..
Although the isolation level determines the type and duration of locks, the table hinds inside the FROM clause can still override the setting from isolation. For example:
USE pubs
GO
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
GO
BEGIN TRANSACTION
SELECT au_lname FROM authors WITH (NOLOCK)
GO
Notice that even the above SQL BATCH used SERIALIZABLE isolation level, the WITH NOLOCK still overrides it, in this case, serialization is not guaranteed.
Cursor concurrency options
The declaration of a cursor includes a SELECT statement, the SELECT statement in a cursor definition is subject to the same transaction locking rules that apply to any other SELECT statement.
Cursors also support their own concurrency specifications, some of which generate additional locks on the rows in each fetch. These scroll locks are held until the next fetch operation or until the cursor is closed, whichever comes first.
Generally speaking, there are two types of concurrency options --- optimistic and pessimistic. By default, the pessimistic is used. When optimistic is used, there’s no lock on the record that is fetched by the cursor, so the content of the record could be changed by another user. Optimistic currency can dramatically benefit the performance and scalability of your application. For example, you have a website which is used to sell the train tickets before Chinese lunar new year. Thousands of users could access your website and try to book tickets. In this case, you don’t want to lock anything, so that other user can access data at any time. (By the way, .NET Framework DataSet object uses optimistic concurrency mode.)
Here, if you choose optimistic currency, then you choose no locks; if you choose pessimistic concurrency, then you choose the same transaction locking rules that apply to any other SELECT statement. (For example, if a cursor is inside an explicit transaction section, then it uses the rules of the explicit transaction.)
References:
MSDN
SQL-Server-Performance.Com Performance Tuning Tip
(http://www.sql-server-performance.com/)
Locking in Microsoft SQL Server
http://www.mssqlcity.com/Articles/Adm/SQL70Locks.htm
Optimistic Concurrency and DataSet Updates
http://www.dotnetbips.com/displayarticle.aspx?id=273
2004年12月1日
#
2004年11月30日
#
这个Blog里还有“文章”分类,那里有一些我摘录的文章,别忘了去看看,谢谢!
In this article, I would like to talk about team structure based on what I am experiencing.
--- From Software Engineering a practitioner's approach fifth edition ---
--- begin
Mantei suggests three generic team organizations:
(1) Democratic decentralized (DD)
(2) Controled decentralized (CD)
(3) Controled centralized (CC)
--- end
Currently the team that I am on belongs to the third category --- CC, which is described as a sort of team structure that completes tasks faster.
CC is the oldest team structure in the Software Developement industry, but unfortunately I had neither experience with it nor knowledge about it until I got this job. Frankly, I felt very uncomfortable with this structure, and I was even mentally tortured by it in the first 5 months, although I believe it's a good structure now.
I believe most of the teams in China are CD, you seldom have a chance to work with a CC team, so let me talk about how it looks like.
Our team has 5 members now, there is one chief developer who is also called team leader. The team is totally centrally controled by this guy. This guy has really more experience in terms of software development, he also has sort of decisive personality. He's the one who is able ot make a decision right after the problem is clear, and will try to stick to his decision (very stubborn).
What made me unconfortable is: he talks to everyone almost every hour if the deadline is tight! He stands beside you and always asks the same question: "How is it going?" This brings a lot of pressure on me and on everyone in our team. So the concerns about how to answer his question was always bugging me. Also the team leader doesn't have a lot of specific tasks to do (except for the application framework), he always participate in solving all the issues.
I am still working in this team, and I think I will survive here for longer time. The reason is I found I got used to it already, and believe our team can work more efficient then other teams since our team is CC team.
So what are the benefits from CC?
First of all, you are not on your own when you are working, you always have a partner (the leader) working with you. It's more or less a kind of "pair programming" ( if you ever tried pair programming, I bet you will definatly conclude that 1 + 1 > 2 ). What's more, the leader is the one who understands each one's ability and advantage. So if you have an issue that cannot be resolved by you and the leader, the leader will find the most useful person to help you. So here comes the better resource management benefit.
Secondly, it's a good approach to enforce inside team regulations like code naming conventions and some other best practices. You will also find it's a good way to enforce refactory. Generaly, a regular code review is usually executed by one of your teamates, there are a variety of reasons that a code review will not be performed well. In our case, a code review will only be executed by the team lead, which is more doable.
Thirdly, the process of development can be mesured more acurately than any other team structure, and the reason is obvious.
I personly like pair programming, so I like: "CC + pair programming!"
The downsides of CC:
After talking about all the benefits, there are really some defects.
(1) The whole team depends on the team lead's ability. The team lead must be more skilled than others, also it requires the team lead to have good communication skill.
(2) This structure is not suitable for solving complicated business problems, for this kind of problem you need more people's visions.
(3) The team lead cares too much, and is easy to feel tired than others.
Maybe you want to try this structure once you are the team lead.
If you had experienced the similar team structure or you don't think this structure can work, let's talk about it. Anything about this topic is welcomed!
2004年11月29日
#
今天生病在家,n觉醒来,本想继续昨天的古墓丽影(还是老游戏好玩!),转念一想还是做点更有意义的事情,于是就花了几分钟创建了这个Creek的Blog. 自此宣布我的思想小屋终于开了一扇窗子!
很久以前看过第一个Blog,当时并没有想到给自己也创建一个。因为当时很忙,并不是工作很忙,而是当时我整个人都在为一件事情而不断的奋斗着,思想如此集中,以至于根部不需要自醒,更谈不上开什么窗子。半年以前我的这目标达到了(熟悉我的人知道我说的是什么吧

),每天的生活又变成了“上班,下班,吃饭,睡觉……”。枯燥的生活使得时间穿梭如飞,同时我的思想又多了起来,但是这些思想是混乱的,就好似两军对阵,敌人就在前方,我的军队却在四面八方。
怎样对事物有正确的认识,怎样使我以及我周围的事物不再枯燥,怎样把我的军队集中在一起…… 就成了我目前以及将来生活的一个主题。
古人云:“吾日三醒吾身”(哪个人说的来着?我去google一下),又有俗话说:“理不辩不明”。基于以上两句名言,今天在这里开一个Blog,留下我的思想,记下我的经历,目的有二:(1) 帮助自己自醒 ,或者说强迫自己自醒;(2)与来者讨论不同的观点,从而达到“明理”。
[按语:不知道这是不是一次“五分钟热血”,希望自己以后不要懒得提笔]
在此附有对Blog的解释:
blog
[Definition]
blog :A frequent, chronological publication of personal thoughts and Web links.
[Information]
A blog is often a mixture of what is happening in a person's life and what is happening on the Web, a kind of hybrid diary/guide site, although there are as many unique types of blogs as there are people.
People maintained blogs long before the term was coined, but the trend gained momentum with the introduction of automated published systems, most notably Blogger at blogger.com. Thousands of people use services such as Blogger to simplify and accelerate the publishing process.
Blogs are alternatively called web logs or weblogs. However, "blog" seems less likely to cause confusion, as "web log" can also mean a server's log files.
最近我在玩的两个游戏是:古墓丽影2,帝国时代2。
前几个星期加入了国内的浩方网络游戏平台,哇,一般同时在线的有5000多人,我就开始寻找网上的菜鸟选手一起玩帝国时代2,这样可以人我宰割(可惜,比我水平差的人极少极少)
早就知道在帝国时代2里,发展经济相当重要了。我见过有人使用数列,甚至高等学的一些知识,推算并证明在不同的时代应该生产怎样的资源。这一切的一切都是为了发展经济,可是发展经济只有一个目的,就是要比别人更早的生产出攻击力更强大的部队。
仔细想想,这好像和个人的生活很相似啊,我们上班赚钱,下了班就用各种各样的方式把钱消费掉,比如吃饭,旅游,打球,看电影,划船,滑冰,滑雪等等。另外我们还学习,学习的目的很明确,就是能够使我们保住工作,或者找到更好的工作,专更多的钱;赚钱的目的也很明确,就是为了娱乐;娱乐的目的也很明确,使我们有好的心情和热情去投入到工作当中。
我在打游戏中还发现,即使我又一支攻击力很强的骑兵小分队,敌人却可以凭借一小撮长枪兵全歼我的整个小分队!甚至敌人可以用具有同等攻击力,可数量更少的骑兵打败我。这就是“用兵”的问题了。
生活中,我们常常会觉得时间过得很快,生活枯燥乏味。这就好比,你在游戏当中只会发展经济,却不会用兵打仗,这两方面是相辅相成,缺一不可的。生活当中,工作和学习就相当于发展经济,娱乐就相当于用兵打仗,所以我们一定要花时间将两方面都做好,因为人的满足感就来自于这里。
工作学习、娱乐;再工作学习、娱乐。这就是人的生活模式。建议您再看清各个环节的目的后,花时间却建设每一个部分。
[按语:此乃一家之言,仿造以上生活模式者,如将来产生生活问题,本人不承担任何责任!:-) ]
最近给公司开发一个Web reporting system, 前端有若干张报表,reporting engine采用的是微软最新推出的Reporting Services; 数据库采用 SQL Server 2000 Standard Edition; 数据库的数据来源于分散在Internet上的20个左右服务器。我们在自己的reporting server上开发了一个Web Services, 其它的服务器通过调用我们的Web Services将数据传输到我们的服务器上。
我个人目前负责MS Reporting Service创建报表。这个东西限制很大,但也有自己的灵活性,主要优势是相对于SQL Server来说是Native的,所以性能方面要比Cystal Report 以及Active Report等好得多。
以前也在数据库上面开发过东西,但是对Stored Procedure并没有很多的经验,现在要做报表,就必须用Select Statement实现很多相对复杂的逻辑。所以最近在这方面有所长进。并且看着自己写的几百行的SQL statement,并且最终可以得到结果(对错,就不知道了),真是很高兴。我的Team里面还是高收如云啊,和他们在一起确实进步很快。
哎,本来还想再说几句,我的输入法TMD不好用。