來源: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