來源:http://bbs.xml.org.cn/blog/more.asp?name=hongrui&id=10283
JdbcTemplate為什末包含javax.sql.DataSource ，而不是用connections，因?yàn)槭褂肈ataSource有很多優(yōu)點(diǎn)，
我們?cè)趶?fù)雜的應(yīng)用中如果使用connections（當(dāng)然可以使用 DataSource.getConnection()得到），
必須捕捉SQLExceptions，這樣spring框架無法處理 SQLException異常，在拋出異常時(shí)，無法關(guān)閉connection。
connection為什末不能共享？DataSource.getConnection()得到connection實(shí)例，一般都不相同，這由連接池的具體實(shí)現(xiàn)控制，
所以大家不要使用oracle的臨時(shí)表，因?yàn)槿绻看芜B接都不一樣的話，下次就沒有臨時(shí)表了。
建立連接是消耗時(shí)間的，在一段時(shí)間內(nèi)，connection只能由一個(gè)用戶使用，為了避免transaction產(chǎn)生沖突，一些jdbc驅(qū)動(dòng)不支持多線程訪問同一個(gè)connection。還有一個(gè)更致命的問題，眾所周知，transaction是基于connection的，即使多個(gè)用戶使用一個(gè)連接，大家在一個(gè)事務(wù)內(nèi)操作數(shù)據(jù)庫，一個(gè)數(shù)據(jù)庫操作rollback，所有的數(shù)據(jù)庫操作全部rollback，所以一直保持一個(gè)打開的connection代價(jià)是很大的。
我只有在兩個(gè)方法中處理一個(gè)事務(wù)時(shí)，把 connection作為變量傳遞。
關(guān)于statement,resultset和connection的問題
statement,resultset屬于弱refrence，即如果statement關(guān)掉，resultset就會(huì)被自動(dòng)釋構(gòu),弱 refrence的做法不保險(xiǎn)，所以JDBC3.0開始明確規(guī)定了如果connection被關(guān)，所有statement都應(yīng)該關(guān),不過這取決于使用的數(shù)據(jù)庫驅(qū)動(dòng)。
應(yīng)該DBMS 執(zhí)行操作后，顯式的關(guān)閉statement ，因?yàn)樵赾onnection關(guān)閉前，JDBC statement仍舊處于打開狀態(tài)，當(dāng)返回resultset后，關(guān)閉statement是必要的，尤其在遇到異常的時(shí)候。
如果不使用 connection pool可以直接關(guān)閉connection，不考慮statement的關(guān)閉，使用連接池的時(shí)候，務(wù)必關(guān)閉statement，否則你的連接馬上被用光，使用statement pooling除外。
192.168.108.25/AppA的a.jsp里有一個(gè)iframe為b.jsp,a和b跨域,如何讓這個(gè)iframe自適應(yīng)高度？
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>
需要查詢某字段是否包含一個(gè)值111是否存在于1111,2111,1112,1121,1113,中 ,
因?yàn)楦鶕?jù)","逗號(hào)分開，要求的答案是：不存在。
用傳統(tǒng)的like '%111,%',顯然不合適，這樣雖然111不存在但是依然能查到該條記錄。
所以應(yīng)該用以下語句實(shí)現(xiàn)：
select * from Table where ','+columA? like '%,111,%'
like '%AAA%'?? 這樣的左右模糊查詢不能用上索引,Oracle沒法通過B-TREE找到相應(yīng)的葉子節(jié)點(diǎn)，位圖索引也是一樣
而like '...%'和 Like '%...'是可以走索引的，后者需要reverse一下
使用where instr(column_name,'AAA')> 0沒有什么效果
如果確定like部分選擇性很強(qiáng)，試試：
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%'模糊查詢無法走索引，影響執(zhí)行速度。經(jīng)測(cè)試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? ;
這個(gè)方法要求like查詢出的記錄不能太多，在我的應(yīng)用中，這一方法使sql效率提高了近10倍。
CAP原理(CAP Theorem)
Consistency(一致性), 數(shù)據(jù)一致更新，所有數(shù)據(jù)變動(dòng)都是同步的
Availability(可用性),
好的響應(yīng)性能
Partition tolerance(分區(qū)容錯(cuò)性) 可靠性
CAP原理指的是，這三個(gè)要素最多只能同時(shí)實(shí)現(xiàn)兩點(diǎn)，不可能三者兼顧
http://www.javaeye.com/articles/2367
BASE模型反ACID模型，完全不同ACID模型，犧牲高一致性，獲得可用性或可靠性：
Basically
Available基本可用。支持分區(qū)失敗(e.g. sharding碎片劃分?jǐn)?shù)據(jù)庫)
Soft state軟狀態(tài)
狀態(tài)可以有一段時(shí)間不同步，異步。
Eventually consistent最終一致，最終數(shù)據(jù)是一致的就可以了，而不是時(shí)時(shí)高一致。
http://lovewhzlq.javaeye.com/blog/619965
Sharding:
Sharding(分片)，與分區(qū)(Partition)不一樣，分區(qū)不能跨數(shù)據(jù)庫
http://www.dbanotes.net/database/database_sharding.html
今天做一個(gè)jsp的驗(yàn)證碼程序，把驗(yàn)證碼的繪制寫在一個(gè)jsp里，發(fā)現(xiàn)在調(diào)用時(shí)總是出現(xiàn)getOutputStream() has already
been called for this response異常，搞得一頭霧水，看似自己重復(fù)調(diào)用了，因?yàn)樵诔绦蜃詈笫沁@樣輸出的
ImageIO.write(image, “JPEG”, response.getOutputStream());
但是仔細(xì)檢查了程序，并沒有問題，不過最后還是解決了，問題出在%>與<%之間的空行，把換行都去掉就OK了。
因?yàn)锳pplication
Server在處理編譯jsp時(shí)對(duì)于％>和<％之間的內(nèi)容一般是原樣輸出，而且默認(rèn)是PrintWriter，而你卻要進(jìn)行流輸
出：ServletOutputStream，這樣做相當(dāng)于試圖在Servlet中使用兩種輸出機(jī)制，就會(huì)發(fā)生getOutputStream()
has already been called for this response的錯(cuò)誤
詳細(xì)請(qǐng)見《More Java Pitfill》一書的第二部分 Web層Item 33：試圖在Servlet中使用兩種輸出機(jī)制 270
而且如果有換行，對(duì)于文本文件沒有什么問題，但是對(duì)于其它格式，比如AutoCAD、Word、Excel等文件
下載下來的文件中就會(huì)多出一些換行符0×0d和0×0a，這樣可能導(dǎo)致某些格式的文件無法打開，有些也可以正常打開。
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>";// 標(biāo)題部分
?? ???? String regex3 = "imgs/[([0-9])]+.(jpg|gif|png|bmp)";//取圖片
輸入例子可產(chǎn)生正則表達(dá)式
http://sourceforge.net/projects/quickrex/
在線測(cè)試
http://www.fileformat.info/tool/regex.htm
rails2.0為了防范CSRF (Cross-Site Request
Forgery)攻擊，提供了一個(gè)小小的手段，那就是protect_from_forgery
http://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection/ClassMethods.html
三次握手Three-way Handshake
一個(gè)虛擬連接的建立是通過三次握手來實(shí)現(xiàn)的
1. (B) --> [SYN] --> (A)
假如服務(wù)器A和客戶機(jī)B通訊. 當(dāng)A要和B通信時(shí)，B首先向A發(fā)一個(gè)SYN (Synchronize) 標(biāo)記的包，告訴A請(qǐng)求建立連接.
注意: 一個(gè) SYN包就是僅SYN標(biāo)記設(shè)為1的TCP包(參見TCP包頭Resources).
認(rèn)識(shí)到這點(diǎn)很重要，只有當(dāng)A受到B發(fā)來的SYN包，才可建立連接，除此之外別無他法。因此，如果你的防火墻丟棄所有的發(fā)往外網(wǎng)接口的SYN包，那么你將不
能讓外部任何主機(jī)主動(dòng)建立連接。
2. (B) <-- [SYN/ACK] <--(A)
接著，A收到后會(huì)發(fā)一個(gè)對(duì)SYN包的確認(rèn)包(SYN/ACK)回去，表示對(duì)第一個(gè)SYN包的確認(rèn)，并繼續(xù)握手操作.
注意: SYN/ACK包是僅SYN 和 ACK 標(biāo)記為1的包.
3. (B) --> [ACK] --> (A)
B收到SYN/ACK 包,B發(fā)一個(gè)確認(rèn)包(ACK)，通知A連接已建立。至此，三次握手完成，一個(gè)TCP連接完成
Note: ACK包就是僅ACK 標(biāo)記設(shè)為1的TCP包. 需要注意的是當(dāng)三此握手完成、連接建立以后，TCP連接的每個(gè)包都會(huì)設(shè)置ACK位
這就是為何連接跟蹤很重要的原因了.
沒有連接跟蹤,防火墻將無法判斷收到的ACK包是否屬于一個(gè)已經(jīng)建立的連接.一般的包過濾(Ipchains)收到ACK包時(shí),會(huì)讓它通過(這絕對(duì)不是個(gè)
好主意). 而當(dāng)狀態(tài)型防火墻收到此種包時(shí)，它會(huì)先在連接表中查找是否屬于哪個(gè)已建連接，否則丟棄該包
四次握手Four-way Handshake
四次握手用來關(guān)閉已建立的TCP連接
1. (B) --> ACK/FIN --> (A)
2. (B) <-- ACK <-- (A)
3. (B) <-- ACK/FIN <-- (A)
4. (B) --> ACK --> (A)
注意: 由于TCP連接是雙向連接, 因此關(guān)閉連接需要在兩個(gè)方向上做。ACK/FIN 包(ACK 和FIN
標(biāo)記設(shè)為1)通常被認(rèn)為是FIN(終結(jié))包.然而, 由于連接還沒有關(guān)閉, FIN包總是打上ACK標(biāo)記.
沒有ACK標(biāo)記而僅有FIN標(biāo)記的包不是合法的包，并且通常被認(rèn)為是惡意的
連接復(fù)位Resetting a connection
四次握手不是關(guān)閉TCP連接的唯一方法. 有時(shí),如果主機(jī)需要盡快關(guān)閉連接(或連接超時(shí),端口或主機(jī)不可達(dá)),RST
(Reset)包將被發(fā)送. 注意在，由于RST包不是TCP連接中的必須部分, 可以只發(fā)送RST包(即不帶ACK標(biāo)記).
但在正常的TCP連接中RST包可以帶ACK確認(rèn)標(biāo)記
請(qǐng)注意RST包是可以不要收到方確認(rèn)的?
無效的TCP標(biāo)記Invalid TCP Flags
到目前為止，你已經(jīng)看到了 SYN, ACK, FIN, 和RST 標(biāo)記. 另外，還有PSH (Push) 和URG (Urgent)標(biāo)記.
最常見的非法組合是SYN/FIN 包. 注意:由于 SYN包是用來初始化連接的, 它不可能和 FIN和RST標(biāo)記一起出現(xiàn). 這也是一個(gè)惡意攻擊.
由于現(xiàn)在大多數(shù)防火墻已知 SYN/FIN 包, 別的一些組合,例如SYN/FIN/PSH, SYN/FIN/RST,
SYN/FIN/RST/PSH。很明顯，當(dāng)網(wǎng)絡(luò)中出現(xiàn)這種包時(shí)，很你的網(wǎng)絡(luò)肯定受到攻擊了。
別的已知的非法包有FIN
(無ACK標(biāo)記)和"NULL"包。如同早先討論的，由于ACK/FIN包的出現(xiàn)是為了關(guān)閉一個(gè)TCP連接，那么正常的FIN包總是帶有 ACK
標(biāo)記。"NULL"包就是沒有任何TCP標(biāo)記的包(URG,ACK,PSH,RST,SYN,FIN都為0)。
到目前為止，正常的網(wǎng)絡(luò)活動(dòng)下，TCP協(xié)議棧不可能產(chǎn)生帶有上面提到的任何一種標(biāo)記組合的TCP包。當(dāng)你發(fā)現(xiàn)這些不正常的包時(shí)，肯定有人對(duì)你的網(wǎng)絡(luò)不懷好意。
來源:http://doubao.javaeye.com/blog/267207
http://hi.baidu.com/abcserver/blog/item/aa1a347310c335148601b07c.html