锁定老帖子 主题:标题都不知道要怎么改才好
该帖已经被评为隐藏帖
|
|
---|---|
作者 | 正文 |
发表时间:2009-08-14
最后修改:2009-08-14
说教并没有多大的用处,指出错误本身这是好的.但是如果可以的话,指一条解决方案更能让人欣慰.
我在理解这个问题的时候也想到了静态变量 本身的问题, 它不管你对象的实例有多少 ,只是脑子在解决问题的思路上有些短路,贴出来也是有种当局者迷,旁观者更能看清问题的关键 或者说,我想要的只是一个解决方案,有没有好点的方法在不用设计数据库的情况下满足需求 |
|
返回顶楼 | |
发表时间:2009-08-14
lz 你怎么了
|
|
返回顶楼 | |
发表时间:2009-08-15
咋把代码删了?
一般的过程是这样的: 浏览器发出http请求,server接到请求是静态资源就到硬盘上找,动态的就调“平台framework”来响应。 你看一般的framework的代码,都是从httprequest搞起的。framework起来的时间,一般都来个初始化,就是这个时间,你的类被加载到了内存,类变量得到初始化(好像是iii吧?),一般的framework是在接到第一个request进行这样的动作。接到命令,framework把长长的url跟request对应到你的类当中的行为,并准备好执行这个行为需要的变量值。一般的framework在找到相应的类的时候(你的action子类?),会创建这个类的一个实例,调用这个实例相应的函数,得到结果后,返回给客户端东东,这个创建的实例的生命一般就结束鸟。等下一个request过来,又会有个亲实例蛋生。生死天命,你写的子类的实例,生死权完全控制在framework里。其实这个跟线程没什么关系。一般的framework还是把一个request放到一个thread里面执行。如果iii是实例变量,那么像你的情况每次request得到的都是一个新实例当中的iii的值,在这里是执行完你程序后的值,如果是static的,也就是类变量了,那么类变量是所有实例共享的,所以,你每次request,不管是张三还是李四的request,iii都被他们搞。所以搞出来的成果就是大家作用的结果。 至于你说的 引用 对于一个用户来讲,上传完成后,上传列表会清空,如果用户此时上传了两张图片,就没有了操作,直接关了页面,几天后用户又来发帖,上次没处理的图片还会在上传列表中,在这一块就需要 线程安全,或者是用别的什么 ? 还是其本身在数据库设计这一块就做得很好 ?
首先你说的东东涉及到2个request,在不同request之间看到相同的东东,用实例变量肯定是不行的了。那咋办ni.... 一种方法是“永久化”,就是说把先头request搞出的东东放到别的地方先存起来,比如数据库啊,文本啊,先塞到硬盘先,当然别的地方也可以是memcache什么的。这个过程要什么ORM转换啦什么的,总之,等第二个request过来的时候我能把它找出来就可以了。另一种方法呢,就是把这个信息放在你自己的系统里,用static!...完全可以。只不过不好static一个简单的int,而要static一个超级强大的类的实例。这个强在类的实例能够根据实例所在的运行期环境中得到足够的信息(cookie啦,session啦等等,一般framework会做好的),对应出相应的结果。 嗯,基本就是这个样子了。 |
|
返回顶楼 | |
发表时间:2009-08-15
再多说点,问题的本质是http是个无状态的协议,就是server端不保留相应客户端在server的状态。不像ftp,telnet会保留客户端的状态,比如当前访问目录等客户端状态。rtsp也是stateful的。这里说的客户端是送reqeust请求的东东,浏览器啦,QQ啦,python urllib啦。。。不是坐在屏幕前的张三李四,小狗小猫。http连客户端的状态都搞不定,更不用说张三李四小猫小狗的状态了。所以就有了现在泛滥的各种http协议上的framework来搞定客户端的状态。然后你的活就是在framework上搞定小猫小狗的状态。你如果想把这些东东都放到内存里,也可以,就是server down的话,什么东东就都死翘翘了。所以一般都是把小猫小狗的状态经过变态的范型分析,对象关系转换搞到数据库里。每次请求过来都从数据库里翻出来,改完,再塞进去。中间换过来换过去的。不过说的字挺多,其实这一路走下来,也没多长时间。可以用firebug看看request里除了url,还有什么东东客户端扔到了server上。然后在server debug下,从call stack一路trace下来,过程基本就清楚了。哎,aix天太热,睡不觉就打字了。
|
|
返回顶楼 | |
发表时间:2009-08-15
为什么。我什么都没看到?
|
|
返回顶楼 | |
发表时间:2009-08-15
感谢 redaready 提供解决问题的思路...
谢谢... |
|
返回顶楼 | |