来源:http://bbs.xml.org.cn/blog/more.asp?name=hongrui&id=10283
JdbcTemplate为什末包含javax.sql.DataSource ，而不是用connections，因为使用DataSource有很多优点，
我们在复杂的应用中如果使用connections（当然可以使用 DataSource.getConnection()得到），
必须捕捉SQLExceptions，这样spring框架无法处理 SQLException异常，在抛出异常时，无法关闭connection。
connection为什末不能共享？DataSource.getConnection()得到connection实例，一般都不相同，这由连接池的具体实现控制，
所以大家不要使用oracle的临时表，因为如果每次连接都不一样的话，下次就没有临时表了。
建立连接是消耗时间的，在一段时间内，connection只能由一个用户使用，为了避免transaction产生冲突，一些jdbc驱动不支持多线程访问同一个connection。还有一个更致命的问题，众所周知，transaction是基于connection的，即使多个用户使用一个连接，大家在一个事务内操作数据库，一个数据库操作rollback，所有的数据库操作全部rollback，所以一直保持一个打开的connection代价是很大的。
我只有在两个方法中处理一个事务时，把 connection作为变量传递。
关于statement,resultset和connection的问题
statement,resultset属于弱refrence，即如果statement关掉，resultset就会被自动释构,弱 refrence的做法不保险，所以JDBC3.0开始明确规定了如果connection被关，所有statement都应该关,不过这取决于使用的数据库驱动。
应该DBMS 执行操作后，显式的关闭statement ，因为在connection关闭前，JDBC statement仍旧处于打开状态，当返回resultset后，关闭statement是必要的，尤其在遇到异常的时候。
如果不使用 connection pool可以直接关闭connection，不考虑statement的关闭，使用连接池的时候，务必关闭statement，否则你的连接马上被用光，使用statement pooling除外。
192.168.108.25/AppA的a.jsp里有一个iframe为b.jsp,a和b跨域,如何让这个iframe自适应高度？
a.jsp
<iframe src="http://192.168.2.97/AppB/b.jsp" id="b_iframe" scrolling="no" frameborder="0"></iframe>
b.jsp
<iframe id='c_iframe' height='0' width='0' src='http://192.168.108.25/AppA/c.jsp' style='display:none' ></iframe>
<script>
var b_height = Math.max(document.body.scrollHeight,document.body.clientHeight);
var c_iframe = document.getElementById('c_iframe');
c_iframe.src = c_iframe.src+'#'+b_height;
</script>
c.jsp
<script>
var hash_url = window.location.hash;
var hash_height = hash_url.split('#')[1]+'px';
var b_iframe = window.parent.parent.document.getElementById('b_iframe');
b_iframe.style.height = hash_height;
</script>
需要查询某字段是否包含一个值111是否存在于1111,2111,1112,1121,1113,中 ,
因为根据","逗号分开，要求的答案是：不存在。
用传统的like '%111,%',显然不合适，这样虽然111不存在但是依然能查到该条记录。
所以应该用以下语句实现：
select * from Table where ','+columA like '%,111,%'
like '%AAA%' 这样的左右模糊查询不能用上索引,Oracle没法通过B-TREE找到相应的叶子节点，位图索引也是一样
而like '...%'和 Like '%...'是可以走索引的，后者需要reverse一下
使用where instr(column_name,'AAA')> 0没有什么效果
如果确定like部分选择性很强，试试：
select * from xxfl where rowid in (select rowid from xxfl where hphm like '%34443%' ) and jgsj between to_date('xxxx-xx-xx xx:xx:xx','yyyy-mm-dd hh24:mi:ss') and to_date('xxxx-xx-xx xx:xx:xx','yyyy-mm-dd hh24:mi:ss');
参考:
http://www.javaeye.com/topic/653713
http://www.itpub.net/viewthread.php?tid=1218563
http://sandish.itpub.net/post/4899/464369
别人的笔记:
sql中的like '%xx%'模糊查询无法走索引，影响执行速度。经测试itpub版主ifree的index_ffs+rowid方法比较有效，记录一下。
这里是示例：
scott@ORCL> CREATE INDEX SCOTT.i_dept_name
2 ON SCOTT.DEPT(DNAME)
3 ;
Index created.
scott@ORCL> Analyze Table SCOTT.DEPT Compute Statistics ;
Table analyzed.
scott@ORCL> select * from scott.dept where
2 rowid in (
3 select /*+ index_ffs(a i_dept_dname) */
4 rowid from scott.dept a where dname like '%A%')
5 ;
这个方法要求like查询出的记录不能太多，在我的应用中，这一方法使sql效率提高了近10倍。
CAP原理(CAP Theorem)
Consistency(一致性), 数据一致更新，所有数据变动都是同步的
Availability(可用性),
好的响应性能
Partition tolerance(分区容错性) 可靠性
CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾
http://www.javaeye.com/articles/2367
BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性，获得可用性或可靠性：
Basically
Available基本可用。支持分区失败(e.g. sharding碎片划分数据库)
Soft state软状态
状态可以有一段时间不同步，异步。
Eventually consistent最终一致，最终数据是一致的就可以了，而不是时时高一致。
http://lovewhzlq.javaeye.com/blog/619965
Sharding:
Sharding(分片)，与分区(Partition)不一样，分区不能跨数据库
http://www.dbanotes.net/database/database_sharding.html
今天做一个jsp的验证码程序，把验证码的绘制写在一个jsp里，发现在调用时总是出现getOutputStream() has already
been called for this response异常，搞得一头雾水，看似自己重复调用了，因为在程序最后是这样输出的
ImageIO.write(image, “JPEG”, response.getOutputStream());
但是仔细检查了程序，并没有问题，不过最后还是解决了，问题出在%>与<%之间的空行，把换行都去掉就OK了。
因为Application
Server在处理编译jsp时对于％>和<％之间的内容一般是原样输出，而且默认是PrintWriter，而你却要进行流输
出：ServletOutputStream，这样做相当于试图在Servlet中使用两种输出机制，就会发生getOutputStream()
has already been called for this response的错误
详细请见《More Java Pitfill》一书的第二部分 Web层Item 33：试图在Servlet中使用两种输出机制 270
而且如果有换行，对于文本文件没有什么问题，但是对于其它格式，比如AutoCAD、Word、Excel等文件
下载下来的文件中就会多出一些换行符0×0d和0×0a，这样可能导致某些格式的文件无法打开，有些也可以正常打开。
String regex = "<a.*?/a>";//取链接
Pattern pattern = Pattern.compile(regex, Pattern.CASE_INSENSITIVE);
Matcher mt = pattern.matcher(str);
while (mt.find()) {
String s=mt.group();
}
String regex2 = ">.*?</a>";// 标题部分
String regex3 = "imgs/[([0-9])]+.(jpg|gif|png|bmp)";//取图片
输入例子可产生正则表达式
http://sourceforge.net/projects/quickrex/
在线测试
http://www.fileformat.info/tool/regex.htm
rails2.0为了防范CSRF (Cross-Site Request
Forgery)攻击，提供了一个小小的手段，那就是protect_from_forgery
http://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection/ClassMethods.html
三次握手Three-way Handshake
一个虚拟连接的建立是通过三次握手来实现的
1. (B) --> [SYN] --> (A)
假如服务器A和客户机B通讯. 当A要和B通信时，B首先向A发一个SYN (Synchronize) 标记的包，告诉A请求建立连接.
注意: 一个 SYN包就是仅SYN标记设为1的TCP包(参见TCP包头Resources).
认识到这点很重要，只有当A受到B发来的SYN包，才可建立连接，除此之外别无他法。因此，如果你的防火墙丢弃所有的发往外网接口的SYN包，那么你将不
能让外部任何主机主动建立连接。
2. (B) <-- [SYN/ACK] <--(A)
接着，A收到后会发一个对SYN包的确认包(SYN/ACK)回去，表示对第一个SYN包的确认，并继续握手操作.
注意: SYN/ACK包是仅SYN 和 ACK 标记为1的包.
3. (B) --> [ACK] --> (A)
B收到SYN/ACK 包,B发一个确认包(ACK)，通知A连接已建立。至此，三次握手完成，一个TCP连接完成
Note: ACK包就是仅ACK 标记设为1的TCP包. 需要注意的是当三此握手完成、连接建立以后，TCP连接的每个包都会设置ACK位
这就是为何连接跟踪很重要的原因了.
没有连接跟踪,防火墙将无法判断收到的ACK包是否属于一个已经建立的连接.一般的包过滤(Ipchains)收到ACK包时,会让它通过(这绝对不是个
好主意). 而当状态型防火墙收到此种包时，它会先在连接表中查找是否属于哪个已建连接，否则丢弃该包
四次握手Four-way Handshake
四次握手用来关闭已建立的TCP连接
1. (B) --> ACK/FIN --> (A)
2. (B) <-- ACK <-- (A)
3. (B) <-- ACK/FIN <-- (A)
4. (B) --> ACK --> (A)
注意: 由于TCP连接是双向连接, 因此关闭连接需要在两个方向上做。ACK/FIN 包(ACK 和FIN
标记设为1)通常被认为是FIN(终结)包.然而, 由于连接还没有关闭, FIN包总是打上ACK标记.
没有ACK标记而仅有FIN标记的包不是合法的包，并且通常被认为是恶意的
连接复位Resetting a connection
四次握手不是关闭TCP连接的唯一方法. 有时,如果主机需要尽快关闭连接(或连接超时,端口或主机不可达),RST
(Reset)包将被发送. 注意在，由于RST包不是TCP连接中的必须部分, 可以只发送RST包(即不带ACK标记).
但在正常的TCP连接中RST包可以带ACK确认标记
请注意RST包是可以不要收到方确认的?
无效的TCP标记Invalid TCP Flags
到目前为止，你已经看到了 SYN, ACK, FIN, 和RST 标记. 另外，还有PSH (Push) 和URG (Urgent)标记.
最常见的非法组合是SYN/FIN 包. 注意:由于 SYN包是用来初始化连接的, 它不可能和 FIN和RST标记一起出现. 这也是一个恶意攻击.
由于现在大多数防火墙已知 SYN/FIN 包, 别的一些组合,例如SYN/FIN/PSH, SYN/FIN/RST,
SYN/FIN/RST/PSH。很明显，当网络中出现这种包时，很你的网络肯定受到攻击了。
别的已知的非法包有FIN
(无ACK标记)和"NULL"包。如同早先讨论的，由于ACK/FIN包的出现是为了关闭一个TCP连接，那么正常的FIN包总是带有 ACK
标记。"NULL"包就是没有任何TCP标记的包(URG,ACK,PSH,RST,SYN,FIN都为0)。
到目前为止，正常的网络活动下，TCP协议栈不可能产生带有上面提到的任何一种标记组合的TCP包。当你发现这些不正常的包时，肯定有人对你的网络不怀好意。
来源:http://doubao.javaeye.com/blog/267207
http://hi.baidu.com/abcserver/blog/item/aa1a347310c335148601b07c.html