2008-04-09
我喜欢Ruby的原因
刚看到“姜太公”说开始不喜欢Ruby，读了一遍帖子，觉得。。。青菜萝卜各有所爱吧。
本想跟贴讨论，但觉得那样的争论很无谓，毕竟代码说明问题
Java
Ruby
这个可能不怎么说明问题。在程序里面，经常会用到xml数据容器，那么
要表达：
*在 Java 里*
* 在 Ruby 里 *
这里例子都是搬来的，更多在http://www.rubyrailways.com/sometimes-less-is-more
本想跟贴讨论，但觉得那样的争论很无谓，毕竟代码说明问题
Java
import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
public class Test
{
public static void main(String[] args)
{
try {
BufferedReader in = new BufferedReader(new FileReader("test.txt"));
StringBuffer sb = new StringBuffer();
String str;
while ((str = in.readLine()) != null)
{ sb.append(str + "\n"); }
in.close();
String result = sb.toString();
Pattern sentencePattern = Pattern.compile("(.*?\\.)\\s+?");
Pattern javaPattern = Pattern.compile("Ruby");
Matcher matcher = sentencePattern.matcher(result);
while (matcher.find()) {
String match = matcher.group();
Matcher matcher2 = javaPattern.matcher(match);
if (matcher2.find())
System.err.println(match);
}
} catch (IOException e)
{
e.printStackTrace();
}
}
}
Ruby
File.read('test.txt').scan(/.*?\. /).each { |s| puts s if s =~ /Ruby/ }
这个可能不怎么说明问题。在程序里面，经常会用到xml数据容器，那么
要表达：
<node name="a">
<node name="b">
<node name="d"/>
<node name="e"/>
</node>
<node name="c">
<node name="f"/>
<node name="g"/>
<node name="h"/>
</node>
</node>
*在 Java 里*
Tree a = new Tree("a");
Tree b = new Tree("b");
Tree c = new Tree("c");
a.addChild(b);
a.addChild(c);
Tree d = new Tree("d");
Tree e = new Tree("e");
b.addChild(d);
b.addchild(e);
Tree f = new Tree("f");
Tree g = new Tree("g");
Tree h = new Tree("h");
c.addChild(f);
c.addChild(g);
c.addChild(h);
* 在 Ruby 里 *
tree = a {
b { d e }
c { f g h }
}
这里例子都是搬来的，更多在http://www.rubyrailways.com/sometimes-less-is-more
评论
myxex
2008-04-27
rubynroll 写道
myxex 写道
一个小小的建议,这帖锁了吧,语言之间爱恶的讨论,便如宗教之争,何必呢.
没有宗教信仰的人，当然无所谓宗教之争。
无心研究语言特性的人，自然无需参与此贴，一边看着就行，何必来此说风凉话呢？
我使用C/C++很有一段时间了也曾有“用什么语言无所谓”的想法。可最近两年想法逐渐改变，认为语言特性对软件开发的许多方面会产生深远影响，而讨论这种影响，以及为什么会有这种影响都不是没有意义的事。
即使严肃的讨论最终不幸被口水淹没，也希望大家能够保持清醒的头脑，否则JE就和CSDN没什么两样了。
行，我标明自己的语言立场是ruby。
但帖子里某些“讨论”近乎人身攻击，哪来清醒这两个字？
rubynroll
2008-04-27
myxex 写道
一个小小的建议,这帖锁了吧,语言之间爱恶的讨论,便如宗教之争,何必呢.
没有宗教信仰的人，当然无所谓宗教之争。
无心研究语言特性的人，自然无需参与此贴，一边看着就行，何必来此说风凉话呢？
我使用C/C++很有一段时间了也曾有“用什么语言无所谓”的想法。可最近两年想法逐渐改变，认为语言特性对软件开发的许多方面会产生深远影响，而讨论这种影响，以及为什么会有这种影响都不是没有意义的事。
即使严肃的讨论最终不幸被口水淹没，也希望大家能够保持清醒的头脑，否则JE就和CSDN没什么两样了。
myxex
2008-04-27
一个小小的建议,这帖锁了吧,语言之间爱恶的讨论,便如宗教之争,何必呢.
rubynroll
2008-04-27
各位，我不了解PHP，不过这里谈的是语言特性在实现一些功能时是否很有意义，就数据库连接这个问题，ruby的伪代码估计就是：
那么，在do_something后面跟的那个闭包里面，如果有意外发生导致中途退出，则数据库连接会确保被正确关闭。
或者以下这种按需关闭的：
其实这里确保资源回收的是begin...ensure...end机制，闭包只是使这种机制可以很好的被包装起来，使用时更加方便而已。
那么如果PHP有类似begin...ensure...end的机制，当然可以实现类似的回收资源，但是如果缺少闭包功能（或者函数不是一等公民）的话，实现起来不免就罗嗦了。
至于那个考操作系统回收资源(通过关闭socket)来关闭数据库，应该不是最佳选择。再者，如果以多线程方式运行，操作系统进程级别回收资源的机制就不会发生作用，例如线程中打开的socket不会被自动销毁。
另外，一个脚本语言的实现是否是“线程安全”的，要看在一个进程中是否允许多个实例，每个实例是否拥有单独的状态机，例如lua就是线程安全的。从C ruby的api来看，是不具备“线程安全”这个条件的。还请对C ruby实现有研究者来谈谈。
def do_something
@db = conn_to_db()
if @db
begin
yield @db
ensure
close_db_conn(@db)
end
end
end
do_something do |db|
....
end
那么，在do_something后面跟的那个闭包里面，如果有意外发生导致中途退出，则数据库连接会确保被正确关闭。
或者以下这种按需关闭的：
def do_something
begin
yield
ensure
close_db_conn(@db) if @db
end
end
do_something do
...
@db = conn_to_db()
...
@db = nil if close_db_conn(@db)
...
end
其实这里确保资源回收的是begin...ensure...end机制，闭包只是使这种机制可以很好的被包装起来，使用时更加方便而已。
那么如果PHP有类似begin...ensure...end的机制，当然可以实现类似的回收资源，但是如果缺少闭包功能（或者函数不是一等公民）的话，实现起来不免就罗嗦了。
至于那个考操作系统回收资源(通过关闭socket)来关闭数据库，应该不是最佳选择。再者，如果以多线程方式运行，操作系统进程级别回收资源的机制就不会发生作用，例如线程中打开的socket不会被自动销毁。
另外，一个脚本语言的实现是否是“线程安全”的，要看在一个进程中是否允许多个实例，每个实例是否拥有单独的状态机，例如lua就是线程安全的。从C ruby的api来看，是不具备“线程安全”这个条件的。还请对C ruby实现有研究者来谈谈。
自言200801
2008-04-26
robbin 写道
我就觉得特有意思，不逼不知道，这一逼就给我逼出来原形了，越逼越漏洞百出，越逼越事实清楚，搞了半天，您两位不但连ruby的基本概念缺乏，合着连PHP，线程，进程这些概念都一团浆糊，没办法，继续科普吧。
人身攻击的的话我就不回复了，否则就跑题了。咱们集中火力谈PHP的数据库连接的释放问题。前面说过了PHP有四种部署运行方式：CGI方式、Apache module方式、IIS方式和FastCGI方式。
这四种方式当中，除了CGI方式之外，都是PHP解释器常驻内存，因此如果你在应用程序当中不使用长连接，那么如果不及时释放数据库连接，就会导致连接泄漏问题。严重的话，会导致数据库服务器无法连接。
而CGI方式因为每次请求进程销毁，因此不会有连接问题，但是CGI是一种非常低效率的方式，但凡稍微有点规模的生产应用都不会采用CGI方式。只要你的web应用每天有几千次请求，CGI方式就会面临性能瓶颈。
首先你自己介绍说你的系统是生产系统，那么我假设你不会采用CGI方式运行，所以如果你连接关闭处理的不好，一定会面临数据库连接释放的问题。
接着你否认了这一点，通过引用PHP官方网站错漏百出的翻译文字，企图说明你采用的是CGI方式运行，所以没有连接释放问题。
于是我又告诉你，如果你采用CGI方式的话，的确没有释放问题。但是这也同时说明了你的所谓生产系统压根就没什么人在用。
其实我特别惊讶的是，连PHP这种根本都不支持线程的基本知识都不知道的人，胡吹自己做了XX的PHP企业系统，估计也只有小白才会相信。
最后给你科普CGI不是我的义务，但是看在你以CGI方式部署了所谓的生产系统之后，又对CGI运行方式一无所知的份了，我不得不给你科普一下，否则又不知道你要闹出来多少常识性笑话。
我说robbin啊robbin啊，我只是想让你就下面的话认个小小的错:
robbin 写道
你这种代码是有严重的问题的，一旦程序执行到中间出错退出，数据库连接就无法被正常关闭。你之所以一直没有碰到问题是因为你开发的系统没有遭遇大并发和高负载，算是走狗屎运罢了。
我已重复了好多次啦，我跟你讨论的是“数据库连接是否能正常关闭的问题”，
你一看到“an instance of the PHP interpreter”被PHP的官方网站翻译成了“一个 PHP 解释器线程”，就断定我连PHP，线程，进程这些概念都一团浆糊，又没细看我的所有回复又在那乱说我们的PHP系统如何如何。
我只是引用官方网站的话，连英文版的我都没看到，难道引用别人的话还要去修改，
而且你找来的英文版的时间是：Fri, 25 Apr 2008，而中文版的时间是：Sun, 25 Nov 2007
英文版的时间明显比中文版的新。
你自己都把“an instance of the PHP interpreter”翻译成了“一个PHP解释器进程实例”，你还要去计较别人翻译错了！
我说
自言200801 写道
给我科普线程、CGI的知识虽然是多此一举，不过我还是心领啦，但是下次讨论问题请专业点，OK？
是间接告诉你，请你不要再跟我说教啦，就你目前的水平还远远不到给我科普的层次，
至于Ruby/Rails吗，也先请robbin给你的粉丝或JavaEye的管理员下道圣旨:不要再乱删我的回贴，
我还没炮轰Ruby/Rails呢，就被删了两贴了。
还有，我再告诉你我们的系统还在用，用得好好的，OCILogOff从没出过问题，
我再告诉你，亿阳信通这么个垄断性质的上市公司早已放言要替换我们的系统，
但是3年过去啦，我们的系统还没被替换，还在用，你知道为什么吗？不是因为PHP有多强，
而是因为我用Java开发的爱立信BSC网元告警系统目前无法取代，
很多PHP开发的系统只是构建在爱立信BSC网元告警系统上面，这些系统虽然数据库表多，代码也多，
但不要求高并发，也不用考虑负载问题，这些用PHP写的web层次的系统很次要，顶多是个配角。
说难听点我对web开发很不屑。
好啦，以后不会再谈论任何关于以前公司的事情，各位也不用费心思琢磨我到底是谁。
再强调一次，我跟你讨论的是“数据库连接是否能正常关闭的问题”。
最后，请到网上找个2004年前的php.tar.gz文件，解压后，找到ext/oci8这个目录，在目录下打开oci8.c文件
我已不想让你认错啦，我要发段oci8.c文件中的源代码让你马上不再说话。
/* {{{ proto bool ocilogoff(int conn)
Disconnect from database */
PHP_FUNCTION(ocilogoff)
{
#if 0
this function does nothing any more. server-connections get automagiclly closed on
request-end. connection handles will "dissappear" as soon as they are no longer
referenced. as this module makes heavy use of zends reference-counting mechanism
this is the desired behavior. it has always been a bad idea to close a connection that
has outstanding transactions. this way we have a nice-clean approach.
(thies@thieso.net 20000110)
oci_connection *connection;
zval **conn;
if (zend_get_parameters_ex(1, &conn) == FAILURE) {
WRONG_PARAM_COUNT;
}
OCI_GET_CONN(connection,conn);
connection->is_open = 0;
zend_hash_apply(list, (apply_func_t) _stmt_cleanup TSRMLS_CC);
if (zend_list_delete(connection->id) == SUCCESS) {
RETURN_TRUE;
} else {
RETURN_FALSE;
}
#endif
}
rubynroll
2008-04-26
liusong1111 只是想说明一下闭包用于事务管理（例如这里就是确保数据库关闭）是很方便的....怎么说着说着又扯的这么远了?
资源回收如果靠操作系统来完成毕竟有很多局限（例如有些资源回收要求一定顺序，或者有些资源操作系统无法自动回收），而编程语言如果提供了相应的设施，自然更加灵活好用了。操作系统回收资源一般就当作最后一道盾牌来“收尸”。
资源回收如果靠操作系统来完成毕竟有很多局限（例如有些资源回收要求一定顺序，或者有些资源操作系统无法自动回收），而编程语言如果提供了相应的设施，自然更加灵活好用了。操作系统回收资源一般就当作最后一道盾牌来“收尸”。
robbin
2008-04-26
自言200801 写道
哈哈，这位mcpssx朋友，虽然我不认识你，也不知道你为什么要来参战，
不过呢，我可以给你提个醒，呵呵，这里的“偶像”们大多都死要面子的，自己扯淡了就转移话题，
死不认错，就怕一认错，粉丝们可就心灰意冷啦，想想崇拜了如此多年，心目中“偶像”竟然那么的不堪一击。
要不，你先休息一下，我来当当主力。
挺好玩的，我竟然意外地发现心理学在这种“战斗”中有如此多的功效，
上次在 <<主题：一门天生就能损害人眼视力的语言－>Erlang>> http://www.javaeye.com/topic/179337里
知道多玩几下就好啦。
让“偶像”们变成“呕像”已变成我每天两小时当中的乐趣啦。
哈哈
要说脸皮厚者真是莫过于此。自己都漏洞百出，连ruby基本概念，进程线程概念，PHP的部署，CGI方式等等统统压根不懂，还真是拿无知当有趣，不过的确有趣的很，逗逗你们，看你们暴露出一个又一个无知的常识性错误，我觉得很娱乐。嘿嘿，不过我也就今天有空，明天就没空逗你们玩了。
robbin
2008-04-26
mcpssx 写道
robbin 写道
来吧，继续科普吧，又露怯了。拜托你搞搞清楚，mod_ruby是猴年马月的东西？再搞搞清楚，mod_ruby能不能用来跑Rails。如果你连Rails怎么部署都不知道，我可以认为，你没有资格在这个帖子里面讨论。
谢谢，那就请您apache多线程部署一下mod_rails吧！
或者请您在任何一个支持多线程的服务器（注意是系统线程，不是什么green thread)啊，部署一个多线程的ror给我们看看，ruby的线程安全是真么表现出比php的优势的！
嘿嘿，继续露怯，咱们继续科普。首先你的逻辑思维能力有问题。我说你根本不懂mod_ruby，你回复说我说，你有本事给我多线程部署mod_rails来跑。请问我的帖子是如何推导出来你的回贴的？你给我讲讲中间的逻辑推导关系？
其次，我多次强调Rails不是线程安全的，这就是说Rails不能以多线程方式运行(PHP也是这样的)。但是很遗憾，明显我白白给你科普了这么久，Rails/PHP不能以多线程方式运行这个基本概念还是没能灌输到你的榆木脑袋里面，于是你又说出了“部署一个多线程的ror给我们看看，ruby的线程安全是真么表现出比php的优势的！”这种无知的话。真是无知者无畏阿。
不过关于mod_rails的话题，我还是有兴趣回答一下的，我才刚刚研究过mod_rails，并且写了篇博客来介绍mod_rails，你有兴趣可以到我的博客去看。
mod_rails和mod_php5的运行机制完全两码事，mod_php5的机制是把PHP解释器加载在Apache的进程里面运行的，所以此时Apache不应该以多线程方式运行；但是mod_rails的机制并不是这样，而是自己启动若干ruby管理进程，由这些管理进程来控制更多的Rails进程的启动，Rails进程和Apache之间通过Unix Socket通讯，因此在这张情况下，Apache用多进程跑也罢，用多线程跑也罢，都无所谓。
robbin
2008-04-26
mcpssx 写道
1，是吗，就是你承认前面的什么连接泄露都是扯淡了？
2，不如我给你科普一下吧，ruby线程是所谓green thread根本就没产生任何一个系统线程，我只是举了lua的例子说明这玩意根本就不是什么python，c语言里面概念的线程。
3，apache多线程更是好笑，谢谢您的关心，全世界php运行听说占一半，还没听说因此就等死了的。
看来全世界人民的素质都提高了啊！
1、CGI方式也会导致连接泄漏，这一点和其他方式没有本质区别，但是因为进程会被销毁，所以泄漏不会造成严重的问题。但是你必须清楚一点，CGI方式不能被用在生产环境当中。你可以拿一个玩具来举例，但是这种东西没有价值。
2、这就是你无知了。用户线程和系统线程都是线程系统，而且用户线程在很多情况下比系统线程更有优势。
3、这是因为真正部署PHP的人都不像你那么无知，知道不能用apache多线程方式去运行PHP。
robbin
2008-04-26
自言200801 写道
首先对删除我两个回贴的人表示抗议，要是管理员删除的，请给出个理由，哪里违返论坛规则啦？
要是因为我在跟robbin唱腔，搞得robbin的粉丝们不爽被投隐藏，我只能借用下面贴子中的一句话:
http://javaeye-admin.group.javaeye.com/group/topic/4828
OK，接下来再反击一下robbin，
我被删的贴子中有一个回复是这样的:
robbin，我拜托你好好看看我在这个贴子中的所有回复好不好！
还有给你的网址里头的内容你看完了没有？那是PHP的官方网站！
我让robbin好好看看我在这个贴子中的所有回复，是想让他明白，他在跟我讨论的是什么问题？
如果robbin没时间看的话，那我在这说给你听:
首先，我没有鼓吹PHP有如何如何的好，我在“主题：我开始不喜欢ruby了”http://www.javaeye.com/topic/180517?page=7
里头早已表明了我现在对PHP的态度。
接着，在这个贴子中我看到liusong1111问了这么个问题：
Web开发中，闭包的影响力可能没那么大。我不懂php，想问问没有闭包的php是怎么处理数据库连接的打开关闭的。
闭包的威力更多表现在逻辑处理和框架级上。我们的逻辑代码就大量（很自然的）用了它。没有它会是灾难。
然后我说到：
以前我用PHP写程序的时候，好像没听说有“闭包”这么个词，现在不知道有没有，3年没去关注PHP啦，
关于PHP处理数据库连接的打开关闭，我这有以前开发的系统的两个自定义函数，
紧接着liusong1111又问我:
我回答说:
我们以前写PHP的时候从不关心disconnection是否正常关闭的，现在系统用了5年啦，还在用，
disconnection相关的问题没碰到过。
数据库不是长连接，一般都是在<body>前放个connection()，在</body>后放个disconnection，
具体细节我不清楚啦，都3年不去搞PHP啦，即使是这样反反复复的connection()与disconnection，
系统性能还是很快的。
robbin看到我说的上面这段话后，他回复如下：
你这种代码是有严重的问题的，一旦程序执行到中间出错退出，数据库连接就无法被正常关闭。你之所以一直没有碰到问题是因为你开发的系统没有遭遇大并发和高负载，算是走狗屎运罢了。
然后我回到:
那我以前算是走狗屎啦，我们的系统不需要大并发和高负载，丢失点数据重来一次都可以，
最重要现在还在用，谁会为了不必要的大并发和高负载去整很多没用的东西，
要是apache不幸死掉了，一秒钟重启就好啦，系统停半小时都不打紧，也不在乎那一秒钟。
这就有点像以前我用java开发多线程程序，而不用ruby做是一个道理，合理的场合选合适的方法。
P.S 我现在两年多不搞应用层次的开发啦，要是你想说很多大道理，我只管听就是啦，我听后，认为不对的地方就插两句。
接着我又说了一大堆用于移动公司内部的系统，
第二天又想起了这个“数据库连接是否能正常关闭的问题”，然后我就去baidu查了一个小时资料，
在这个网址中:
http://www.php.net/manual/zh/features.persistent-connections.php
讲的是"数据库永久连接",而我已经叫robbin注意上面的红色字体，我在上面已说了“数据库不是长连接”
我只是引用了这个网址中的下面这段话：
第一种方法是将 PHP 用作一个“外壳”。以这种方法运行，PHP 会为向 web 服务器提出的每个 PHP 页面请求生成并结束一个 PHP 解释器线程。由于该线程会随每个请求的结束而结束，因此任何在这个线程中利用的任何资源（例如指向 SQL 数据库服务器的连接）都会随线程的结束而关闭。
我根本就不在意是“线程”还是“进程”，英文版我也没看，我只想告诉robbin一个答案：
线程中利用的任何资源（例如指向 SQL 数据库服务器的连接）都会随线程的结束而关闭
然后我再给出下面这个网址：
http://www.php.net/manual/zh/ref.oci8.php
引用了里面的一段话:
oci_connect() 使用的连接缓冲区会在脚本执行完毕后或者明确地关闭了连接句柄时被清空。
结合这两段话，我只想告诉robbin“数据库连接是否能正常关闭的问题”是有答案的，
我们的系统运行了5年都没在OCILogOff这个函数上出过问题，并不是走狗屎运。
接着，我想robbin还是没明白我们一直在讨论什么问题，我给他的两个网址的内容我想他看都没看完，
只抓住“线程”这两个字在那里自个得意得很，发表了下面的话:
说你走了狗屎运，你还不信。以你描述的这种方式运行PHP的确不会导致连接池泄漏问题，但是会导致一个更严重的问题，就是很容易被DOS攻击。因为你这种运行方式是每个请求过来创建PHP进程(注意不是线程)，页面执行完毕就销毁进程。只要我瞬时发送上千个并发请求，你的Web服务器就会因为忙于大量创建PHP进程的开销而瘫痪。
再纠正你一个常识性错误，PHP不是线程安全的，所以Apache要跑PHP的话，不能用多线程方式跑，PHP是一个纯进程的解释器，压根不支持线程，很难想像一个号称有多少年PHP经验的人连这个常识都不清楚。
robbin还以为我引用的上面两个网址中的段落是我自己说的，robbin还弄出个DOS攻击，
我真快笑疯啦，真要有DOS攻击，那你快点把移动公司的内部网络赶快搞瘫痪去吧，里面有些系统密码都懒得设。
最后，robbin肯定又在网上不停地找啊找，找到了个英文版的，
发现“an instance of the PHP interpreter”不应该被别人翻译成“一个 PHP 解释器线程”，
中文版的时间是Last updated: Sun, 25 Nov 2007
英文版的时间是Last updated: Fri, 25 Apr 2008
这回好，robbin英文还不错吧，robbin认为是“一个PHP解释器进程实例”，
我英文真的很差，但是robbin认为是“一个PHP解释器进程实例”，
但是这个“进程”的英文单词“process”没在“an instance of the PHP interpreter”中啊，
得啦，反正我英文很差，就随robbin说去吧。
我已经把系统的应用场景都说明白啦，robbin最后还是老是在说DOS，说负载，说线程，
离题已10万8千里。
robbin你就继续说DOS，说负载，说线程吧，我都3年不理PHP啦。
给我科普线程、CGI的知识虽然是多此一举，不过我还是心领啦，但是下次讨论问题请专业点，OK？
要是因为我在跟robbin唱腔，搞得robbin的粉丝们不爽被投隐藏，我只能借用下面贴子中的一句话:
http://javaeye-admin.group.javaeye.com/group/topic/4828
引用
这里属于群体暴力，如果你的追随者多，马上会成为精华帖，如果你的仇人多，立刻就被隐藏。
OK，接下来再反击一下robbin，
我被删的贴子中有一个回复是这样的:
引用
robbin，我拜托你好好看看我在这个贴子中的所有回复好不好！
还有给你的网址里头的内容你看完了没有？那是PHP的官方网站！
我让robbin好好看看我在这个贴子中的所有回复，是想让他明白，他在跟我讨论的是什么问题？
如果robbin没时间看的话，那我在这说给你听:
首先，我没有鼓吹PHP有如何如何的好，我在“主题：我开始不喜欢ruby了”http://www.javaeye.com/topic/180517?page=7
里头早已表明了我现在对PHP的态度。
接着，在这个贴子中我看到liusong1111问了这么个问题：
liusong1111 写道
Web开发中，闭包的影响力可能没那么大。我不懂php，想问问没有闭包的php是怎么处理数据库连接的打开关闭的。
闭包的威力更多表现在逻辑处理和框架级上。我们的逻辑代码就大量（很自然的）用了它。没有它会是灾难。
然后我说到：
自言200801 写道
以前我用PHP写程序的时候，好像没听说有“闭包”这么个词，现在不知道有没有，3年没去关注PHP啦，
关于PHP处理数据库连接的打开关闭，我这有以前开发的系统的两个自定义函数，
/*
函数功能: 连接oracle数据库;
入口参数：无;
返回值:$sql_conn(连接句柄).
*/
function connection(){
$sql_conn = OCILogon("用户名","密码","数据库名") or die;
return $sql_conn;
}
/*
函数功能: 断开oracle数据库连接;
入口参数：
$sql_conn:连接句柄;
返回值:断开连接错误信息.
*/
function disconnection($sql_conn){
return OCILogOff($sql_conn);
}
紧接着liusong1111又问我:
liusong1111 写道
那么你上面那段php程序如何保证一次请求结束后数据库肯定能关闭呢？是每进程一长连接模式吗？需不需每个php页面都调这两个方法？
我回答说:
自言200801 写道
我们以前写PHP的时候从不关心disconnection是否正常关闭的，现在系统用了5年啦，还在用，
disconnection相关的问题没碰到过。
数据库不是长连接，一般都是在<body>前放个connection()，在</body>后放个disconnection，
具体细节我不清楚啦，都3年不去搞PHP啦，即使是这样反反复复的connection()与disconnection，
系统性能还是很快的。
robbin看到我说的上面这段话后，他回复如下：
robbin 写道
你这种代码是有严重的问题的，一旦程序执行到中间出错退出，数据库连接就无法被正常关闭。你之所以一直没有碰到问题是因为你开发的系统没有遭遇大并发和高负载，算是走狗屎运罢了。
然后我回到:
自言200801 写道
那我以前算是走狗屎啦，我们的系统不需要大并发和高负载，丢失点数据重来一次都可以，
最重要现在还在用，谁会为了不必要的大并发和高负载去整很多没用的东西，
要是apache不幸死掉了，一秒钟重启就好啦，系统停半小时都不打紧，也不在乎那一秒钟。
这就有点像以前我用java开发多线程程序，而不用ruby做是一个道理，合理的场合选合适的方法。
P.S 我现在两年多不搞应用层次的开发啦，要是你想说很多大道理，我只管听就是啦，我听后，认为不对的地方就插两句。
接着我又说了一大堆用于移动公司内部的系统，
第二天又想起了这个“数据库连接是否能正常关闭的问题”，然后我就去baidu查了一个小时资料，
在这个网址中:
http://www.php.net/manual/zh/features.persistent-connections.php
讲的是"数据库永久连接",而我已经叫robbin注意上面的红色字体，我在上面已说了“数据库不是长连接”
我只是引用了这个网址中的下面这段话：
引用
第一种方法是将 PHP 用作一个“外壳”。以这种方法运行，PHP 会为向 web 服务器提出的每个 PHP 页面请求生成并结束一个 PHP 解释器线程。由于该线程会随每个请求的结束而结束，因此任何在这个线程中利用的任何资源（例如指向 SQL 数据库服务器的连接）都会随线程的结束而关闭。
我根本就不在意是“线程”还是“进程”，英文版我也没看，我只想告诉robbin一个答案：
线程中利用的任何资源（例如指向 SQL 数据库服务器的连接）都会随线程的结束而关闭
然后我再给出下面这个网址：
http://www.php.net/manual/zh/ref.oci8.php
引用了里面的一段话:
引用
oci_connect() 使用的连接缓冲区会在脚本执行完毕后或者明确地关闭了连接句柄时被清空。
结合这两段话，我只想告诉robbin“数据库连接是否能正常关闭的问题”是有答案的，
我们的系统运行了5年都没在OCILogOff这个函数上出过问题，并不是走狗屎运。
接着，我想robbin还是没明白我们一直在讨论什么问题，我给他的两个网址的内容我想他看都没看完，
只抓住“线程”这两个字在那里自个得意得很，发表了下面的话:
robbin 写道
说你走了狗屎运，你还不信。以你描述的这种方式运行PHP的确不会导致连接池泄漏问题，但是会导致一个更严重的问题，就是很容易被DOS攻击。因为你这种运行方式是每个请求过来创建PHP进程(注意不是线程)，页面执行完毕就销毁进程。只要我瞬时发送上千个并发请求，你的Web服务器就会因为忙于大量创建PHP进程的开销而瘫痪。
再纠正你一个常识性错误，PHP不是线程安全的，所以Apache要跑PHP的话，不能用多线程方式跑，PHP是一个纯进程的解释器，压根不支持线程，很难想像一个号称有多少年PHP经验的人连这个常识都不清楚。
robbin还以为我引用的上面两个网址中的段落是我自己说的，robbin还弄出个DOS攻击，
我真快笑疯啦，真要有DOS攻击，那你快点把移动公司的内部网络赶快搞瘫痪去吧，里面有些系统密码都懒得设。
最后，robbin肯定又在网上不停地找啊找，找到了个英文版的，
发现“an instance of the PHP interpreter”不应该被别人翻译成“一个 PHP 解释器线程”，
中文版的时间是Last updated: Sun, 25 Nov 2007
英文版的时间是Last updated: Fri, 25 Apr 2008
这回好，robbin英文还不错吧，robbin认为是“一个PHP解释器进程实例”，
我英文真的很差，但是robbin认为是“一个PHP解释器进程实例”，
但是这个“进程”的英文单词“process”没在“an instance of the PHP interpreter”中啊，
得啦，反正我英文很差，就随robbin说去吧。
我已经把系统的应用场景都说明白啦，robbin最后还是老是在说DOS，说负载，说线程，
离题已10万8千里。
robbin你就继续说DOS，说负载，说线程吧，我都3年不理PHP啦。
给我科普线程、CGI的知识虽然是多此一举，不过我还是心领啦，但是下次讨论问题请专业点，OK？
我就觉得特有意思，不逼不知道，这一逼就给我逼出来原形了，越逼越漏洞百出，越逼越事实清楚，搞了半天，您两位不但连ruby的基本概念缺乏，合着连PHP，线程，进程这些概念都一团浆糊，没办法，继续科普吧。
人身攻击的的话我就不回复了，否则就跑题了。咱们集中火力谈PHP的数据库连接的释放问题。前面说过了PHP有四种部署运行方式：CGI方式、Apache module方式、IIS方式和FastCGI方式。
这四种方式当中，除了CGI方式之外，都是PHP解释器常驻内存，因此如果你在应用程序当中不使用长连接，那么如果不及时释放数据库连接，就会导致连接泄漏问题。严重的话，会导致数据库服务器无法连接。
而CGI方式因为每次请求进程销毁，因此不会有连接问题，但是CGI是一种非常低效率的方式，但凡稍微有点规模的生产应用都不会采用CGI方式。只要你的web应用每天有几千次请求，CGI方式就会面临性能瓶颈。
首先你自己介绍说你的系统是生产系统，那么我假设你不会采用CGI方式运行，所以如果你连接关闭处理的不好，一定会面临数据库连接释放的问题。
接着你否认了这一点，通过引用PHP官方网站错漏百出的翻译文字，企图说明你采用的是CGI方式运行，所以没有连接释放问题。
于是我又告诉你，如果你采用CGI方式的话，的确没有释放问题。但是这也同时说明了你的所谓生产系统压根就没什么人在用。
其实我特别惊讶的是，连PHP这种根本都不支持线程的基本知识都不知道的人，胡吹自己做了XX的PHP企业系统，估计也只有小白才会相信。
最后给你科普CGI不是我的义务，但是看在你以CGI方式部署了所谓的生产系统之后，又对CGI运行方式一无所知的份了，我不得不给你科普一下，否则又不知道你要闹出来多少常识性笑话。
自言200801
2008-04-26
mcpssx 写道
robbin 写道
mcpssx 写道
robbin先生很有转移问题的天才
1，本来人家说的是php可以自动释放连接，robbin先生似乎无法否认这点，就转而大谈什么ddos攻击。
我已经指出这个与用那种语言毫无关系。
2，robbin先生在php上扣字眼，我也来扣一下。那就是ruby的线程似乎也不太好叫线程，我看好像是lua的协程之类的东西。
3“所以你应该明白ruby无所谓线程安全不安全，只有用Ruby写出来的程序才能谈线程安全不安全的问题”
这就是robbin先生喜欢扣字眼的又一明证了，这样吧，我就算您证明了ruby本身是线程安全的，而ruby写出来的程序有可能是线程不安全的吧。
您扣出来的这个说法有什么意义吗？
这其实是php的又一大优势啊，人家根本就不考虑什么线程问题，这是apache等等调度的事情
有趣，实在有趣！越来越露怯了，这让我的科普工作越来越有价值。
1、CGI方式根本无需释放连接，这一点我从来就不否认。但问题是，你懂不懂什么是CGI方式，CGI方式有什么问题你了解不了解？如果你敢用CGI部署方式来跑生产系统，而且几年都不出问题，那我只能恭喜你，你走狗屎运了。
2、这一条简直是活生生的露怯，再让我给你科普一下吧：ruby的线程就是线程，而协程是ruby 1.9支持的另外一种多任务调度方式。线程是线程，协程是协程，先搞清楚基本概念再来讨论，OK？
3、这不是你说的ruby不是线程安全的吗？我只是告诉你，ruby无所谓线程安全不安全，但是你连这么基本概念都不懂，还兀自强辩自己如何如何不觉得太掩耳盗铃？
引用
这其实是php的又一大优势啊，人家根本就不考虑什么线程问题，这是apache等等调度的事情
嘿嘿，又露怯了不是，请记住一点，Apache是支持多线程的，正是因为PHP不能在多线程环境下跑，所以Apache在运行PHP的时候，不能打开多线程。话你怎么说都可以，但是部署Apache的人如果不清楚这一点，不考虑线程问题，那他就等死吧。
1，是吗，就是你承认前面的什么连接泄露都是扯淡了？
2，不如我给你科普一下吧，ruby线程是所谓green thread根本就没产生任何一个系统线程，我只是举了lua的例子说明这玩意根本就不是什么python，c语言里面概念的线程。
3，apache多线程更是好笑，谢谢您的关心，全世界php运行听说占一半，还没听说因此就等死了的。
看来全世界人民的素质都提高了啊！
哈哈，这位mcpssx朋友，虽然我不认识你，也不知道你为什么要来参战，
不过呢，我可以给你提个醒，呵呵，这里的“偶像”们大多都死要面子的，自己扯淡了就转移话题，
死不认错，就怕一认错，粉丝们可就心灰意冷啦，想想崇拜了如此多年，心目中“偶像”竟然那么的不堪一击。
要不，你先休息一下，我来当当主力。
挺好玩的，我竟然意外地发现心理学在这种“战斗”中有如此多的功效，
上次在 <<主题：一门天生就能损害人眼视力的语言－>Erlang>> http://www.javaeye.com/topic/179337里
知道多玩几下就好啦。
让“偶像”们变成“呕像”已变成我每天两小时当中的乐趣啦。
哈哈
gigix
2008-04-26
robbin 写道
来吧，继续科普吧，又露怯了。拜托你搞搞清楚，mod_ruby是猴年马月的东西？再搞搞清楚，mod_ruby能不能用来跑Rails。如果你连Rails怎么部署都不知道，我可以认为，你没有资格在这个帖子里面讨论。
人家老早说了，人家是搞研究的，这种毫无趣味的实用工程问题，不入人家法眼的
robbin
2008-04-26
mcpssx 写道
mcpssx 写道
2，ruby更不是线程安全的。
前面说：
刚才竟然漏回复一个极品贴了，请问你知道什么叫做线程安全吗？你给我解释解释什么叫做Ruby不是线程安全的？或者你给我说说看C语言是不是线程安全的，Java语言是不是线程安全的？
后面说：
当然我也说过PHP不是线程安全的，但是PHP和Ruby不是一码事，PHP本身就不支持多线程，所以PHP内置的函数基本上都不能在多线程环境下面运行。也许你会问PHP不支持多线程，怎么可能在多线程环境下面跑？这是因为Apache可以以Module的方式加载PHP，而Apache2.0以上版本是可以以多线程方式运行的，这样的结果就把不支持多线程，而且内置函数库也没有考虑过多线程执行可能性的PHP带到了多线程环境下，这在PHP的部署方式当中是要避免的情况。因此你可以说PHP不是线程安全的，你也可以说Rails不是线程安全的，唯独不能说Ruby不是线程安全。
============================================================
看了半天，robbin先生好像是证明了
大家只能说php不是线程安全的，但是不能说ruby不是线程安全的。
我也来较一下真，就算果真如此，你前面的php里面的”线程“和后面ruby里面的“线程”是一会事吗？
你大谈apache2.0的多线程如何如何，这时要避免部署php，那请问这时候能多线程部署mod_ruby吗？
2，ruby更不是线程安全的。
前面说：
刚才竟然漏回复一个极品贴了，请问你知道什么叫做线程安全吗？你给我解释解释什么叫做Ruby不是线程安全的？或者你给我说说看C语言是不是线程安全的，Java语言是不是线程安全的？
后面说：
当然我也说过PHP不是线程安全的，但是PHP和Ruby不是一码事，PHP本身就不支持多线程，所以PHP内置的函数基本上都不能在多线程环境下面运行。也许你会问PHP不支持多线程，怎么可能在多线程环境下面跑？这是因为Apache可以以Module的方式加载PHP，而Apache2.0以上版本是可以以多线程方式运行的，这样的结果就把不支持多线程，而且内置函数库也没有考虑过多线程执行可能性的PHP带到了多线程环境下，这在PHP的部署方式当中是要避免的情况。因此你可以说PHP不是线程安全的，你也可以说Rails不是线程安全的，唯独不能说Ruby不是线程安全。
============================================================
看了半天，robbin先生好像是证明了
大家只能说php不是线程安全的，但是不能说ruby不是线程安全的。
我也来较一下真，就算果真如此，你前面的php里面的”线程“和后面ruby里面的“线程”是一会事吗？
你大谈apache2.0的多线程如何如何，这时要避免部署php，那请问这时候能多线程部署mod_ruby吗？
来吧，继续科普吧，又露怯了。拜托你搞搞清楚，mod_ruby是猴年马月的东西？再搞搞清楚，mod_ruby能不能用来跑Rails。如果你连Rails怎么部署都不知道，我可以认为，你没有资格在这个帖子里面讨论。
robbin
2008-04-26
mcpssx 写道
robbin先生很有转移问题的天才
1，本来人家说的是php可以自动释放连接，robbin先生似乎无法否认这点，就转而大谈什么ddos攻击。
我已经指出这个与用那种语言毫无关系。
2，robbin先生在php上扣字眼，我也来扣一下。那就是ruby的线程似乎也不太好叫线程，我看好像是lua的协程之类的东西。
3“所以你应该明白ruby无所谓线程安全不安全，只有用Ruby写出来的程序才能谈线程安全不安全的问题”
这就是robbin先生喜欢扣字眼的又一明证了，这样吧，我就算您证明了ruby本身是线程安全的，而ruby写出来的程序有可能是线程不安全的吧。
您扣出来的这个说法有什么意义吗？
这其实是php的又一大优势啊，人家根本就不考虑什么线程问题，这是apache等等调度的事情
有趣，实在有趣！越来越露怯了，这让我的科普工作越来越有价值。
1、CGI方式根本无需释放连接，这一点我从来就不否认。但问题是，你懂不懂什么是CGI方式，CGI方式有什么问题你了解不了解？如果你敢用CGI部署方式来跑生产系统，而且几年都不出问题，那我只能恭喜你，你走狗屎运了。
2、这一条简直是活生生的露怯，再让我给你科普一下吧：ruby的线程就是线程，而协程是ruby 1.9支持的另外一种多任务调度方式。线程是线程，协程是协程，先搞清楚基本概念再来讨论，OK？
3、这不是你说的ruby不是线程安全的吗？我只是告诉你，ruby无所谓线程安全不安全，但是你连这么基本概念都不懂，还兀自强辩自己如何如何不觉得太掩耳盗铃？
引用
这其实是php的又一大优势啊，人家根本就不考虑什么线程问题，这是apache等等调度的事情
嘿嘿，又露怯了不是，请记住一点，Apache是支持多线程的，正是因为PHP不能在多线程环境下跑，所以Apache在运行PHP的时候，不能打开多线程。话你怎么说都可以，但是部署Apache的人如果不清楚这一点，不考虑线程问题，那他就等死吧。
自言200801
2008-04-26
首先对删除我两个回贴的人表示抗议，要是管理员删除的，请给出个理由，哪里违返论坛规则啦？
要是因为我在跟robbin唱腔，搞得robbin的粉丝们不爽被投隐藏，我只能借用下面贴子中的一句话:
http://javaeye-admin.group.javaeye.com/group/topic/4828
OK，接下来再反击一下robbin，
我被删的贴子中有一个回复是这样的:
robbin，我拜托你好好看看我在这个贴子中的所有回复好不好！
还有给你的网址里头的内容你看完了没有？那是PHP的官方网站！
我让robbin好好看看我在这个贴子中的所有回复，是想让他明白，他在跟我讨论的是什么问题？
如果robbin没时间看的话，那我在这说给你听:
首先，我没有鼓吹PHP有如何如何的好，我在“主题：我开始不喜欢ruby了”http://www.javaeye.com/topic/180517?page=7
里头早已表明了我现在对PHP的态度。
接着，在这个贴子中我看到liusong1111问了这么个问题：
Web开发中，闭包的影响力可能没那么大。我不懂php，想问问没有闭包的php是怎么处理数据库连接的打开关闭的。
闭包的威力更多表现在逻辑处理和框架级上。我们的逻辑代码就大量（很自然的）用了它。没有它会是灾难。
然后我说到：
以前我用PHP写程序的时候，好像没听说有“闭包”这么个词，现在不知道有没有，3年没去关注PHP啦，
关于PHP处理数据库连接的打开关闭，我这有以前开发的系统的两个自定义函数，
紧接着liusong1111又问我:
我回答说:
我们以前写PHP的时候从不关心disconnection是否正常关闭的，现在系统用了5年啦，还在用，
disconnection相关的问题没碰到过。
数据库不是长连接，一般都是在<body>前放个connection()，在</body>后放个disconnection，
具体细节我不清楚啦，都3年不去搞PHP啦，即使是这样反反复复的connection()与disconnection，
系统性能还是很快的。
robbin看到我说的上面这段话后，他回复如下：
你这种代码是有严重的问题的，一旦程序执行到中间出错退出，数据库连接就无法被正常关闭。你之所以一直没有碰到问题是因为你开发的系统没有遭遇大并发和高负载，算是走狗屎运罢了。
然后我回到:
那我以前算是走狗屎啦，我们的系统不需要大并发和高负载，丢失点数据重来一次都可以，
最重要现在还在用，谁会为了不必要的大并发和高负载去整很多没用的东西，
要是apache不幸死掉了，一秒钟重启就好啦，系统停半小时都不打紧，也不在乎那一秒钟。
这就有点像以前我用java开发多线程程序，而不用ruby做是一个道理，合理的场合选合适的方法。
P.S 我现在两年多不搞应用层次的开发啦，要是你想说很多大道理，我只管听就是啦，我听后，认为不对的地方就插两句。
接着我又说了一大堆用于移动公司内部的系统，
第二天又想起了这个“数据库连接是否能正常关闭的问题”，然后我就去baidu查了一个小时资料，
在这个网址中:
http://www.php.net/manual/zh/features.persistent-connections.php
讲的是"数据库永久连接",而我已经叫robbin注意上面的红色字体，我在上面已说了“数据库不是长连接”
我只是引用了这个网址中的下面这段话：
第一种方法是将 PHP 用作一个“外壳”。以这种方法运行，PHP 会为向 web 服务器提出的每个 PHP 页面请求生成并结束一个 PHP 解释器线程。由于该线程会随每个请求的结束而结束，因此任何在这个线程中利用的任何资源（例如指向 SQL 数据库服务器的连接）都会随线程的结束而关闭。
我根本就不在意是“线程”还是“进程”，英文版我也没看，我只想告诉robbin一个答案：
线程中利用的任何资源（例如指向 SQL 数据库服务器的连接）都会随线程的结束而关闭
然后我再给出下面这个网址：
http://www.php.net/manual/zh/ref.oci8.php
引用了里面的一段话:
oci_connect() 使用的连接缓冲区会在脚本执行完毕后或者明确地关闭了连接句柄时被清空。
结合这两段话，我只想告诉robbin“数据库连接是否能正常关闭的问题”是有答案的，
我们的系统运行了5年都没在OCILogOff这个函数上出过问题，并不是走狗屎运。
接着，我想robbin还是没明白我们一直在讨论什么问题，我给他的两个网址的内容我想他看都没看完，
只抓住“线程”这两个字在那里自个得意得很，发表了下面的话:
说你走了狗屎运，你还不信。以你描述的这种方式运行PHP的确不会导致连接池泄漏问题，但是会导致一个更严重的问题，就是很容易被DOS攻击。因为你这种运行方式是每个请求过来创建PHP进程(注意不是线程)，页面执行完毕就销毁进程。只要我瞬时发送上千个并发请求，你的Web服务器就会因为忙于大量创建PHP进程的开销而瘫痪。
再纠正你一个常识性错误，PHP不是线程安全的，所以Apache要跑PHP的话，不能用多线程方式跑，PHP是一个纯进程的解释器，压根不支持线程，很难想像一个号称有多少年PHP经验的人连这个常识都不清楚。
robbin还以为我引用的上面两个网址中的段落是我自己说的，robbin还弄出个DOS攻击，
我真快笑疯啦，真要有DOS攻击，那你快点把移动公司的内部网络赶快搞瘫痪去吧，里面有些系统密码都懒得设。
最后，robbin肯定又在网上不停地找啊找，找到了个英文版的，
发现“an instance of the PHP interpreter”不应该被别人翻译成“一个 PHP 解释器线程”，
中文版的时间是Last updated: Sun, 25 Nov 2007
英文版的时间是Last updated: Fri, 25 Apr 2008
这回好，robbin英文还不错吧，robbin认为是“一个PHP解释器进程实例”，
我英文真的很差，但是robbin认为是“一个PHP解释器进程实例”，
但是这个“进程”的英文单词“process”没在“an instance of the PHP interpreter”中啊，
得啦，反正我英文很差，就随robbin说去吧。
我已经把系统的应用场景都说明白啦，robbin最后还是老是在说DOS，说负载，说线程，
离题已10万8千里。
robbin你就继续说DOS，说负载，说线程吧，我都3年不理PHP啦。
给我科普线程、CGI的知识虽然是多此一举，不过我还是心领啦，但是下次讨论问题请专业点，OK？
要是因为我在跟robbin唱腔，搞得robbin的粉丝们不爽被投隐藏，我只能借用下面贴子中的一句话:
http://javaeye-admin.group.javaeye.com/group/topic/4828
引用
这里属于群体暴力，如果你的追随者多，马上会成为精华帖，如果你的仇人多，立刻就被隐藏。
OK，接下来再反击一下robbin，
我被删的贴子中有一个回复是这样的:
引用
robbin，我拜托你好好看看我在这个贴子中的所有回复好不好！
还有给你的网址里头的内容你看完了没有？那是PHP的官方网站！
我让robbin好好看看我在这个贴子中的所有回复，是想让他明白，他在跟我讨论的是什么问题？
如果robbin没时间看的话，那我在这说给你听:
首先，我没有鼓吹PHP有如何如何的好，我在“主题：我开始不喜欢ruby了”http://www.javaeye.com/topic/180517?page=7
里头早已表明了我现在对PHP的态度。
接着，在这个贴子中我看到liusong1111问了这么个问题：
liusong1111 写道
Web开发中，闭包的影响力可能没那么大。我不懂php，想问问没有闭包的php是怎么处理数据库连接的打开关闭的。
闭包的威力更多表现在逻辑处理和框架级上。我们的逻辑代码就大量（很自然的）用了它。没有它会是灾难。
然后我说到：
自言200801 写道
以前我用PHP写程序的时候，好像没听说有“闭包”这么个词，现在不知道有没有，3年没去关注PHP啦，
关于PHP处理数据库连接的打开关闭，我这有以前开发的系统的两个自定义函数，
/*
函数功能: 连接oracle数据库;
入口参数：无;
返回值:$sql_conn(连接句柄).
*/
function connection(){
$sql_conn = OCILogon("用户名","密码","数据库名") or die;
return $sql_conn;
}
/*
函数功能: 断开oracle数据库连接;
入口参数：
$sql_conn:连接句柄;
返回值:断开连接错误信息.
*/
function disconnection($sql_conn){
return OCILogOff($sql_conn);
}
紧接着liusong1111又问我:
liusong1111 写道
那么你上面那段php程序如何保证一次请求结束后数据库肯定能关闭呢？是每进程一长连接模式吗？需不需每个php页面都调这两个方法？
我回答说:
自言200801 写道
我们以前写PHP的时候从不关心disconnection是否正常关闭的，现在系统用了5年啦，还在用，
disconnection相关的问题没碰到过。
数据库不是长连接，一般都是在<body>前放个connection()，在</body>后放个disconnection，
具体细节我不清楚啦，都3年不去搞PHP啦，即使是这样反反复复的connection()与disconnection，
系统性能还是很快的。
robbin看到我说的上面这段话后，他回复如下：
robbin 写道
你这种代码是有严重的问题的，一旦程序执行到中间出错退出，数据库连接就无法被正常关闭。你之所以一直没有碰到问题是因为你开发的系统没有遭遇大并发和高负载，算是走狗屎运罢了。
然后我回到:
自言200801 写道
那我以前算是走狗屎啦，我们的系统不需要大并发和高负载，丢失点数据重来一次都可以，
最重要现在还在用，谁会为了不必要的大并发和高负载去整很多没用的东西，
要是apache不幸死掉了，一秒钟重启就好啦，系统停半小时都不打紧，也不在乎那一秒钟。
这就有点像以前我用java开发多线程程序，而不用ruby做是一个道理，合理的场合选合适的方法。
P.S 我现在两年多不搞应用层次的开发啦，要是你想说很多大道理，我只管听就是啦，我听后，认为不对的地方就插两句。
接着我又说了一大堆用于移动公司内部的系统，
第二天又想起了这个“数据库连接是否能正常关闭的问题”，然后我就去baidu查了一个小时资料，
在这个网址中:
http://www.php.net/manual/zh/features.persistent-connections.php
讲的是"数据库永久连接",而我已经叫robbin注意上面的红色字体，我在上面已说了“数据库不是长连接”
我只是引用了这个网址中的下面这段话：
引用
第一种方法是将 PHP 用作一个“外壳”。以这种方法运行，PHP 会为向 web 服务器提出的每个 PHP 页面请求生成并结束一个 PHP 解释器线程。由于该线程会随每个请求的结束而结束，因此任何在这个线程中利用的任何资源（例如指向 SQL 数据库服务器的连接）都会随线程的结束而关闭。
我根本就不在意是“线程”还是“进程”，英文版我也没看，我只想告诉robbin一个答案：
线程中利用的任何资源（例如指向 SQL 数据库服务器的连接）都会随线程的结束而关闭
然后我再给出下面这个网址：
http://www.php.net/manual/zh/ref.oci8.php
引用了里面的一段话:
引用
oci_connect() 使用的连接缓冲区会在脚本执行完毕后或者明确地关闭了连接句柄时被清空。
结合这两段话，我只想告诉robbin“数据库连接是否能正常关闭的问题”是有答案的，
我们的系统运行了5年都没在OCILogOff这个函数上出过问题，并不是走狗屎运。
接着，我想robbin还是没明白我们一直在讨论什么问题，我给他的两个网址的内容我想他看都没看完，
只抓住“线程”这两个字在那里自个得意得很，发表了下面的话:
robbin 写道
说你走了狗屎运，你还不信。以你描述的这种方式运行PHP的确不会导致连接池泄漏问题，但是会导致一个更严重的问题，就是很容易被DOS攻击。因为你这种运行方式是每个请求过来创建PHP进程(注意不是线程)，页面执行完毕就销毁进程。只要我瞬时发送上千个并发请求，你的Web服务器就会因为忙于大量创建PHP进程的开销而瘫痪。
再纠正你一个常识性错误，PHP不是线程安全的，所以Apache要跑PHP的话，不能用多线程方式跑，PHP是一个纯进程的解释器，压根不支持线程，很难想像一个号称有多少年PHP经验的人连这个常识都不清楚。
robbin还以为我引用的上面两个网址中的段落是我自己说的，robbin还弄出个DOS攻击，
我真快笑疯啦，真要有DOS攻击，那你快点把移动公司的内部网络赶快搞瘫痪去吧，里面有些系统密码都懒得设。
最后，robbin肯定又在网上不停地找啊找，找到了个英文版的，
发现“an instance of the PHP interpreter”不应该被别人翻译成“一个 PHP 解释器线程”，
中文版的时间是Last updated: Sun, 25 Nov 2007
英文版的时间是Last updated: Fri, 25 Apr 2008
这回好，robbin英文还不错吧，robbin认为是“一个PHP解释器进程实例”，
我英文真的很差，但是robbin认为是“一个PHP解释器进程实例”，
但是这个“进程”的英文单词“process”没在“an instance of the PHP interpreter”中啊，
得啦，反正我英文很差，就随robbin说去吧。
我已经把系统的应用场景都说明白啦，robbin最后还是老是在说DOS，说负载，说线程，
离题已10万8千里。
robbin你就继续说DOS，说负载，说线程吧，我都3年不理PHP啦。
给我科普线程、CGI的知识虽然是多此一举，不过我还是心领啦，但是下次讨论问题请专业点，OK？
aaxron
2008-04-26
呵呵, robbin 强.
好贴,留名.慢慢看.
好贴,留名.慢慢看.
robbin
2008-04-26
mcpssx 写道
2，ruby更不是线程安全的。
刚才竟然漏回复一个极品贴了，请问你知道什么叫做线程安全吗？你给我解释解释什么叫做Ruby不是线程安全的？或者你给我说说看C语言是不是线程安全的，Java语言是不是线程安全的？
我老早以前就发明过一个词，叫做“牛逼哄哄的露怯”，嘿嘿，还是让我来给你科普一下吧：
ruby是支持多线程的编程语言，有些ruby的框架很好的利用了这一点，可以在单ruby进程内同时运行多个线程，比方说现在很多基于Rails框架的改良框架，像Merb之类就是可以多线程运行的，他就是线程安全的，而有些ruby框架没有使用多线程特性，甚至没有考虑到多线程运行会带来的一些问题，因此不能以多线程方式运行，比方说Rails框架就是线程不安全的，而Mongrel是多线程运行的，因此在进入Rails处理流程前后必须加锁，这一点经常被Zed Shawn批评。
所以你应该明白ruby无所谓线程安全不安全，只有用Ruby写出来的程序才能谈线程安全不安全的问题。以目前你对ruby的了解情况来看，完全可以证明这么一个道理：黑子是不需要理由，也不需要背景知识的，黑你就是没商量。
当然我也说过PHP不是线程安全的，但是PHP和Ruby不是一码事，PHP本身就不支持多线程，所以PHP内置的函数基本上都不能在多线程环境下面运行。也许你会问PHP不支持多线程，怎么可能在多线程环境下面跑？这是因为Apache可以以Module的方式加载PHP，而Apache2.0以上版本是可以以多线程方式运行的，这样的结果就把不支持多线程，而且内置函数库也没有考虑过多线程执行可能性的PHP带到了多线程环境下，这在PHP的部署方式当中是要避免的情况。因此你可以说PHP不是线程安全的，你也可以说Rails不是线程安全的，唯独不能说Ruby不是线程安全。
robbin
2008-04-26
自言200801 写道
mcpssx 写道
robbin 写道
引用
第一种方法是将 PHP 用作一个“外壳”。以这种方法运行，PHP 会为向 web 服务器提出的每个 PHP 页面请求生成并结束一个 PHP 解释器线程。由于该线程会随每个请求的结束而结束，因此任何在这个线程中利用的任何资源（例如指向 SQL 数据库服务器的连接）都会随线程的结束而关闭。
说你走了狗屎运，你还不信。以你描述的这种方式运行PHP的确不会导致连接池泄漏问题，但是会导致一个更严重的问题，就是很容易被DOS攻击。因为你这种运行方式是每个请求过来创建PHP进程(注意不是线程)，页面执行完毕就销毁进程。只要我瞬时发送上千个并发请求，你的Web服务器就会因为忙于大量创建PHP进程的开销而瘫痪。
再纠正你一个常识性错误，PHP不是线程安全的，所以Apache要跑PHP的话，不能用多线程方式跑，PHP是一个纯进程的解释器，压根不支持线程，很难想像一个号称有多少年PHP经验的人连这个常识都不清楚。
BTW: 一帮人没幽默感，这么极品的帖子我添点油浇点火想烧旺点吧，非板着脸说你robbin着急上火了想和人家拼命。你们也不想想，ruby又不是我大爷，我现在代码都不写了我，又不靠它吃饭，我犯得着？
1，dos？人家不是已经说了是企业应用，考虑个什么dos攻击？
2，ruby更不是线程安全的。
解决dos跟语言什么一点关系都没有，无非是apache, fastcgi各种技术的选择问题，我就不信你ror跟php一样配置，就能避免dos攻击
robbin，我拜托你好好看看我在这个贴子中的所有回复好不好！
还有给你的网址里头的内容你看完了没有？那是PHP的官方网站！
说你是菜鸟，你还不信，非逼我把证据拿出来在堂堂大庭广众之下证明你是菜鸟不可，这不是非逼我做人不厚道吗？
你引用的是PHP官方网站的文档不假，但是你引用是中文翻译手册，而不是英文原文，让我把英文原文贴给你仔细看看：
http://www.php.net/manual/en/features.persistent-connections.php
引用
The first method is to use PHP as a CGI "wrapper". When run this way, an instance of the PHP interpreter is created and destroyed for every page request (for a PHP page) to your web server. Because it is destroyed after every request, any resources that it acquires (such as a link to an SQL database server) are closed when it is destroyed. In this case, you do not gain anything from trying to use persistent connections -- they simply don't persist.
这段话本来很浅显，但是中文翻译错误的离谱，所以我不得不重新翻译一下：
正确的翻译如下 写道
第一种方法是使用PHP以CGI方式运行。在这种运行方式下，每当一个页面请求达到你的Web服务器的时候，都会创建一个PHP解释器进程实例，页面请求执行完毕后进程实例销毁。正是因为每次请求结束后进程被销毁了，所以该PHP进程实例持有的任何资源(例如数据库链接)都会被释放掉。在这种情况下，你根本就不可能使用数据库持久连接，因为他们根本无法被进程保持住。
看明白没有？我不知道是你英文水平太差，还是压根没有PHP的实际部署和运行的经验，犯了常识性错误也就罢了，还拿着错的离谱的中文翻译当个尚方宝剑来使。
如果你还不懂什么叫做CGI方式运行的话，我还可以继续给你科普。 PHP官方网站这篇文章介绍了PHP常见的三种运行方式：CGI方式，Apache Module方式和IIS方式。这三种方式都很容易被DOS，其中CGI方式性能最差，根本不能负载频繁的Web应用。所以我说你走了狗屎运你还不信，你那个系统的负载很低，而且还是一个小型企业内部网系统，否则早就挂了。
至于说避免被DOS引起的服务器资源耗光其实很容易，以独立进程方式运行固定数目的PHP进程就可以避免这个问题，比方说现在使用PHP的大型网站比方说新浪博客都已经这样部署了，只不过你不知道罢，还抱着CGI当块宝呐。顺便说一句Rails不管是FastCGI还是独立的应用服务器比方说Mongrel/Thin也不会碰到这张DOS问题。所以真让你说对了，RoR就是能够避免DOS。
ajoo
2008-04-26
potian 写道
ajoo 写道
要是让我说我为什么喜欢ruby，closure可能是马上会从脑子里跳出来的咚咚。不知道为什么，好像别的特性都无法说服自己why ruby。
ruby的everything is a statement对我这种不可救药的形式主义者也很有吸引力，我喜欢语言有一个大一统的抽象模型，而不是象c++那样spec里面充满了if-else。
但是始终不是很喜欢open class和一些meta programming的功能，比如define_method什么的，感觉太hack了，确实有不好维护的感觉和担忧。
——————一个二把刀的自白
ruby的everything is a statement对我这种不可救药的形式主义者也很有吸引力，我喜欢语言有一个大一统的抽象模型，而不是象c++那样spec里面充满了if-else。
但是始终不是很喜欢open class和一些meta programming的功能，比如define_method什么的，感觉太hack了，确实有不好维护的感觉和担忧。
——————一个二把刀的自白
有是有一点的，但Objective-c也一样 open class，mata programming也很强,苹果用得好好地
要说meta programming ,LISP有过之无不及，Yahoo当年就是买了Paul Graham的web store(?)，大发其财，也算是互联网上电子商务开山之作之一了
什么刀要看什么人拿的，拿不好的刀越锋利就越伤自己，拿的好的刀越锋利越好使
不要没拿就害怕，拿拿这样的刀你还不是手到擒来，呵呵
话说我那会写rparsec（我通共就写过那么一点点ruby代码），当时感觉很爽地用了几个define_method，因为确实一些method的定义有重复模式可寻，而重复性的东西不就是坏味道么？不过过了这么长时间回头一看，我不应该呀。这代码反而更晦涩（或者说更聪明了），读代码总要隔着那么一层动态的东西来读，就象隔靴搔痒。很有一种读c++的宏代码的感觉——脑子要当解释器跑一遍。（俺当年可是很写过些变态的宏的，比mfc的要变态一些）。rdoc也不给面子，楞是不给我define出来的方法生成文档，奶奶的！
当然，跟java这种语言一比，很多时候你被迫要很傻很傻地写代码，也是很折磨人的。建议城管抓住外地闲散ruby/perl程序员，不用费力气揍，就让他用java写些东西，这惩罚度也大概就够了。
liusong1111
2008-04-25
自言200801 写道
liusong1111 写道
自言200801 写道
zsbfree 写道
偶看了几天，觉得很是无聊。偶现在从事asp.net。但是用过rails后就不想再用asp.net，个中原因我就不说了。其实大家争论的一个焦点是： rails到底有没有前途。无论是攻击还是嘲讽！！！，我个人希望攻击的人有空去学习下，自己去做一个小网站，亲身体验下。没有调查就没有发言权。这句话在计算机学科也适用。至于robbin，我个人感觉他太过于激动了。他根本就没有必要加入这场争论。就算以后不用rails,我个人觉得学习也是大有益处的。
还有几个人，不要攻击rails了，你不学习有你的自由。我学习有我的自由。知之为知之，不知为不知。
还有几个人，不要攻击rails了，你不学习有你的自由。我学习有我的自由。知之为知之，不知为不知。
呵呵，我想zsbfree这位老兄没听过明斯基等人所写的<<感知机>>与联结主义认知心理学的网络模型研究之间的趣事吧，
说“攻击”吗，算不上，有些人就爱说不好听的，有些人就爱说好听的，
社会心理学不是有个从众心理吗，
大众人群多数对偶像、名人、专家还有盲从趋向，
说好听的说到极致，以前爱说不好听的也变得爱说好听了。
说不好听的说到极致，以前爱说好听的都闭嘴啦。
回到学术上，一本专说不好听的书能让某一学科的发展停滞10年(或更久或消亡)。
牛人真多，啥都懂。
但如果就是不懂ruby，那，您的分析也就只能采用诸如隐马尔可夫模型了。
哈哈，我说liusong1111啊，都说过两次让你等等啦，我正在构思一篇叫“炮轰Ruby/Rails”的文章，
只要不被封号就保证会让各位看到，
要是有人也像我那么极端，想不停的争论技术细节问题，
说不定我会花两三个月把C Ruby的实现源码与Rails的源码翻个低朝天，
就怕JavaEye上跟我争论的人老是停留在应用层次，一说细点，别人就马上闭嘴啦，那是多么扫兴的事。
我不牛，我还很菜，只是爱走极端，不过要是你也想知道我的研究领域的话，也请你看看:
一门天生就能损害人眼视力的语言－>Erlang http://www.javaeye.com/topic/179337
里面有提到我的研究领域，呵呵，可惜我已请求管理员锁贴啦。
呵呵，我这么没耐心呢？看来去MSN、QQ拯救那些失足沦落文学女青年的时机到了，美女们，等着我，我来了！~
你还没研究，就定了“炮轰”的课题，牛人就是不一样。
Ruby源码我没研究，我想你分享出来会有像dreamhead这些人跟你讨论。
Rails源码我读了不少，很多实现说起来也是一脸的伤心泪啊。要是你有理有据的跟大家分享经验，robbin在那边就偷着乐了，封号这种傻事他能干？
halfmile
- 浏览: 1899 次
- 性别:
- 详细资料
搜索本博客
最近加入圈子
最新评论
-
我喜欢Ruby的原因
rubynroll 写道myxex 写道一个小小的建议,这帖锁了吧,语言之间爱恶 ...
-- by myxex -
我喜欢Ruby的原因
myxex 写道一个小小的建议,这帖锁了吧,语言之间爱恶的讨论,便如宗教之争,何 ...
-- by rubynroll -
我喜欢Ruby的原因
一个小小的建议,这帖锁了吧,语言之间爱恶的讨论,便如宗教之争,何必呢.
-- by myxex -
我喜欢Ruby的原因
各位，我不了解PHP，不过这里谈的是语言特性在实现一些功能时是否很有意义，就数据 ...
-- by rubynroll -
我喜欢Ruby的原因
robbin 写道 我就觉得特有意思，不逼不知道，这一逼就给我逼出来原形了，越逼 ...
-- by 自言200801
评论排行榜