出现这种情况,原因可能是:
1、所有的页面都要继承自 BbsPageBase
2、aspx页面放在 max-templates目录下的某个模板目录下
3、aspx.cs代码文件必须放在 _codes目录下的对应 max-templates 的子目录
最近小峰在开发项目的时候遇到一个问题就是阻塞问题。用的是thinkphp框架,利用ajax请求一次操作,在ajax没有返回结果前,相同程序,其它操作是无效的。然后网上一查,有人和我有一样的问题,下面把该解决方法分享出来。
当同时向服务端发现若干HTTP请求,有时你会发现这些请求可能并非并发完成的,服务器对这些请求进行了排队处理,产生了所谓的PHP阻塞现象。最有可能是脚本进行了session数据的读写,PHP中session默认使用文件系统进行存储的,当进行读写session文件操作时,存储session的文件处于锁定状态,此时其他需要读写session数据的请求需要等待前一个请求完成后才会进行,从而导致PHP阻塞的发生,庆幸的是PHP提供了session_write_close()函数来结束当前session并写入数据。
session阻塞简单演示
创建2个php文件:session_a.php,session_b.php。
<?php
// session_a.php
session_start();
$_SESSION['a'] = date('H:i:s');
// session_write_close();
sleep(5);
echo $_SESSION['a'];
<?php
// session_b.php
session_start();
$_SESSION['b'] = date('H:i:s');
// session_write_close();
sleep(5);
echo $_SESSION['b'];
同时访问这2个脚本,你会发现,其中一个脚本比另一个延迟了5秒。而当我们将文件中的session_write_close()函数注释取消掉后,再来同时访问发现2个脚本可以同时执行了。
session锁定处理机制
顺便提一下,session_commit()是session_write_close()的别名,即也可以使用前者替代后者。
当session_start()调用时,session处理机制默认会打开或创建一个seesion文件,且会立即给这个文件上了一个锁定状态(locked)。当session_commit()调用时或脚本执行完成后该文件会被解锁(unlocked)。
锁定状态有个重要的影响:同时请求使用了session的PHP脚本,并非并列执行的,而是分离的。如果当用户发起了一个请求,同时发起另一个请求便会被阻塞,直至前一个请求完全完成。
Session锁定的好处
请不要勿以为这所谓的阻塞现象是PHP的BUG,当然不是,相反有些时候分离执行才是正确的做法。考虑一下购物车案例:
用户发起A请求,脚本读取用来显示购物车物品的session数据;
在A请求完成之前,用户便点击了“加入购物车”按钮,发送了个B请求;
B等待A请求完成,然后向session中新增数据;
如果没有对session进行锁定会发生什么?
B没有等待A完成,读取并写入session数据;
A请求完成并写入之前读取的session数据,覆盖了上述B写入的数据;
所以,我们在使用session时应当考虑当前实际环境。
ThinkPHP如何解决session阻塞
最近开始使用国内的PHP框架ThinkPHP,便遇见了阻塞问题,因为没仔细看官方文档,调试许久未果,差点一怒之下放弃该框架,后发现配置项里有个“SESSION_AUTO_START”配置,用于自动加载session,果断设置为FALSE,一切恢复正常。
在需要使用session的时候,可以使用PHP自带函数:
session_start();
//...
session_commit(); // 或session_write_close()
也可以用TP风格方式:
session('[start]');
//...
session('[pause]');
1、进入QQ互联平台:http://connect.qq.com/
运行PHP页面,提示“Cannot send session cache limiter – headers already sent by()”或者"function session_start()"错误,让人非常头痛。因为这不是第一次遇到了,为了加深印象,把问题原因分析及解决方法详细写下来,分享给大家。
问题分析:
记得第一次遇到这个问题时,谷歌了很多答案,也有很多种解决方法,但出现这个问题大部分最根本的原因是:当在运行session_start();时是不能有任何输出,而这之前页面已经有出现空行现象,或可以说页面是含有DOM编码的UTF-8页面。
查看页面是否含有DOM编码方法:
1、使用Dreamweaver软件打开页面,查看页面属性(修改-页面属性-标题/编码),查看“包括Unicode签名BOM”项前面是否打勾;
2、记事本打开,另存为时,编码格式为ANSI则不含有DOM,若为UTF-8,基本肯定含有。
解决办法:
通过工具,如:editplus、ultraedit等工具,去掉DOM行即空白行即可解决,具体步骤如下
如图所示:
其它解决方法:
1、页面头部加上:ob_start();//偶尔碰到失效;
2、新建页面,将代码COPY过去,这个方法有时也管用,注意GBK还是UTF-8编码(通常由GBK另存为UTF-8编码时会默认带DOM编码);
3、另一种情况服务器PHP配置问题:修改php.ini中的 session.auto_start = 0 为 session.auto_start = 1;
4、基本上面的可以解决这个问题,还有些很少见的非常规方法,如果不能解决,大家只能谷歌了。
出现这个错误,可能会有几种原因,网上搜索的答案基本也是比较有针对性的一方面,关键在如何去寻找原因,并解决它。
分析一:在数据进行存储并反序列化时编码问题出错
这个原因是很常见的,比方,原本是以GBK编码进行存储,然后是UTF-8编码的,那么在进行unserialize()就会有问题;
解决方法一:将UTF-8编码的数据转换成GBK,PHP语言可以用iconv()函数;
分析二:重写反序列函数
一些情况可以把底层的函数重写,将gb2312转换成utf-8格式之后,每个中文的字节数从2个增加到3个之后导致了反序列化的时候判断字符长度出现了问题,所以需要使用正则表达式将序列化的数组中的表示字符长度的值重新计算一遍,代码如下:
function mb_unserialize($serial_str) {
$out = preg_replace('!s:(\d+):"(.*?)";!se', "'s:'.strlen('$2').':\"$2\";'", $serial_str );
return unserialize($out);
}
解决方法三:对字符数据进行base64_encode,然后serialize序列化,还原提取时,unserialize()再base64_decode