1,
Calendar cd = Calendar.getInstance();
cd.add(Calendar.DATE, 1);//增加一天
?//cd.add(Calendar.MONTH, n);//增加n個月
這里不要使用set方法,也不要使用roll,原因見明海棠文集之日期時間1.0(注:這個帖子很強大)
另外commons-lang里的DateUtils里有一些以add開頭的靜態(tài)方法,例如addMonths(),實際也是調(diào)用add實現(xiàn)的。好像commons-lang2.4以后才有這個功能。

2,java里的格式 yyyy-MM-dd HH:mm:ss
? oracle里的格式 yyyy-MM-dd hh24:mi:ss

?//格式化時間——精確到毫秒并且長度一致，如果用yyyyMMddHHmmssS就會不一致
SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMddHHmmssSSS");


3，

蘇軾《卜算子·黃州定慧院寓居作》
缺月掛疏桐，漏斷人初靜。誰見幽人獨往來？縹緲孤鴻影。
驚起卻回頭，有恨無人省。揀盡寒枝不肯棲，寂寞沙洲冷。
http://zhidao.baidu.com/question/25708793.html?fr=qrl
http://zhidao.baidu.com/question/11411756.html

0 0-15 23 * * ? ? 每天23:00至23:15每分鐘觸發(fā)一次
0 0/5 * * * ????? 每隔5分鐘觸發(fā)一次
0 15 10 L * ? ? ? 每月最后一日的上午10:15觸發(fā)

bean配置的順序:
定時器的工廠bean-->cronbean-->具體實現(xiàn)的bean

Define of cronExpression

http://hi.baidu.com/tonent/blog/item/894e8b525124960a0cf3e3a1.html
http://blog.csdn.net/changsure/archive/2007/03/27/1542194.aspx
http://www.xici.net/b391997/d26742282.htm

1，service方法的transactionAttributes配置為readonly時,
批處理中出現(xiàn)錯誤: ORA-01456: 不可以在 READ ONLY 事務處理中執(zhí)行插入/刪除/更新操作

2,Failed to convert property value of type
錯誤的原因是service屬性應該是接口，而不能是一個類

3,spring2.5支持jdk1.4
readme.txt里有這樣一句:
The Spring Framework 2.5 requires JDK 1.4.2 and J2EE 1.3 (Servlet 2.3, JSP 1.2, JTA 1.0, EJB 2.0). JDK 1.6 is
required for building the framework; for the full build including all aspects, AspectJ is required as well.
core包下有個JdkVersion類，用來判斷jdk版本.代碼里的相關位置對環(huán)境變量進行了判斷，有時候做同一件事提供了兩套方案,高于1.5(或1.6)一種,低于1.5(或1.6)又是一種,構(gòu)建時用1.6版本以1.4編譯,就能在1.4上用了。

4,spring啟動時ApplicationContext
http://www.tkk7.com/jiake/archive/2009/01/07/250235.html

5,屬性命名時不支持第一個字母是小寫，而第二個字母是大寫。
也就是說，對于JavaBean來講，第一個與第二個字母都要小寫
參考：
http://www.javaeye.com/topic/103184
http://www.javaeye.com/topic/88921
http://www.javaeye.com/problems/6293
javabean specification，規(guī)定了一般的屬性名稱首字母小寫，如果遇到前兩個字母大寫的屬性，則getter方法保持屬性名稱不變，例如URL屬性的 getter方法為getURL，但是并沒有規(guī)定類似eTypeName這樣的屬性的getter方法寫成geteTypeName的形式。
如果要符合javabean規(guī)范，則只能將eTypeName改成ETypeName


8,springfuse
Code generation for Spring-based Web applications?

1，JBPM的版本機制允許在數(shù)據(jù)庫中多個同名流程定義共存，流程實例以當時的最新版本來啟動，并且在它的整個生命周期中將保持以相同的流程定義執(zhí)行。當一個新的版本被部署，新的流程實例以新版本啟動，而老的流程實例則以老的流程定義繼續(xù)執(zhí)行。

2，swimlane(泳道)
實際應用中，一個人是一個流程中多個Task的參與者(actor)的情況是很常見的。在jbpm中通過創(chuàng)建一個swimlane并且把swimlane賦給一個task的方式來設置當前task的參與者（actor）。一個業(yè)務流程中的swimlane可以被看做為一個參與者的參與者對象的名稱，當然它不一定是固定的某個人，它可以是一個用戶組，一個特定用戶的角色等。首次執(zhí)行到達一個Task，賦給該Task的一個swimlane就會算出參與者(actor)。
自己的理解:swimlane是一個描述任務接收者的特殊的對象，可以是一個用戶，也可以是一個角色，可以是任何東西，只要能根據(jù)這個swimlane算出有哪些actor

3,JBPM中任務的分配方式有兩種：一種是為task指定一個assignment-handler，既一個實現(xiàn)了AssignmentHandler接口的類；另外一種是為task指定一個swimlane(泳道)，swimlane可以在流程中定義好，一個流程中可以定義若干個swimlane，在定義一個swimlane時同樣也是指定了個實現(xiàn)了AssignmentHandler接口的類，當我們的task指定了一個swimlane后，其效果同我們指定一個assignment-handler效果是一樣的，只不過可以簡化我們?nèi)蝿盏姆峙涔ぷ?
自己的理解:這兩種方式實際上是同一種，可以把swimlane理解為assignment-handler的命名，或者快捷方式，方便重用(assignment-handler是一次性的)。看來swimlane這個名字是個噱頭啊。

4，以圖形化的方式顯示JBPM當前流程的方法及原理分析

http://blog.csdn.net/tuwen/archive/2007/09/12/1782623.aspx

5，jbpmside是一個基于jbpm進行擴展和封裝的開源工作流項目

6, getting started with? jbpm and spring
http://www.theserverside.com/tt/articles/article.tss?l=jBPMandSpring

7，jbpm3.2需要jdk1.5
8，每一個jbpm_processinstance的roottoken有且只有一個。
如果當前token在folk節(jié)點上，則其多個子token在各個分支的節(jié)點上。
可以查到每一個token所屬的流程實例。

我單位物資系統(tǒng)：庫存表kcb，庫存明細kcmx?

當發(fā)生一筆動態(tài)的時候，先查詢庫存表中的庫存數(shù)量，然后加上增減數(shù)量，得到新庫存，update，commit；?

接著把庫存數(shù)量，增減數(shù)量，更改時間分別插入到庫存明細：前次數(shù)量，增減數(shù)量，更改時間。?

問 題：現(xiàn)在有兩條數(shù)據(jù)更改時間很接近? a? 10:51:47:01b? 10:51:46:25? .也就是說兩條數(shù)據(jù)先后更新，而且更新的是同樣一筆物資。于是，a? 條記錄得到的前存數(shù)量和b條記錄得到的前存數(shù)量一樣，（好像叫讀臟數(shù)？）于是記錄b的更新就被當作不存在了！?

系統(tǒng)在隨后的更新中查到的是記錄a更新候的數(shù)據(jù)，一切正常，唯有記錄b? 被忽略了；（于是庫存錯了，領導批了）?

?

還有一個奇怪的問題，就是庫存明細的查詢是用存儲過程作的，為什么select到pb的數(shù)據(jù)窗口之后別的數(shù)據(jù)都是按時間順序排列，唯有上面兩條，a在b之前！時間也會錯？相差太近？?

我以后怎么辦？高人教我

http://blog.csdn.net/qiume/archive/2009/02/26/3938382.aspx
對數(shù)據(jù)庫中的數(shù)據(jù)修改都是在內(nèi)存中完成的，這些修改的結(jié)果可能已經(jīng)寫到硬盤也可能沒有寫到硬盤，如果在操作過程中，發(fā)生斷電或系統(tǒng)錯誤等故障，數(shù)據(jù)庫可以 保證未結(jié)束的事務對數(shù)據(jù)庫的數(shù)據(jù)修改結(jié)果即使已經(jīng)寫入磁盤，在下次數(shù)據(jù)庫啟動后也會被全部撤銷；而對于結(jié)束的事務，即使其修改的結(jié)果還未寫入磁盤，在數(shù)據(jù) 庫下次啟動后會通過事務日志中的記錄進行“重做”，即把丟失的數(shù)據(jù)修改結(jié)果重新生成，并寫入磁盤，從而保證結(jié)束事務對數(shù)據(jù)修改的永久化。這樣也保證了事務 中的操作要么全部完成，要么全部撤銷。

1,jBPM沒有角色的概念,jBPM只有參與者的概念，也就是ActorID，它可以是用戶ID，也可以是角色ID，也可以什么都不是
? http://www.uml.org.cn/workclass/200709306.asp
2,如何獲得某actor的任務
? http://jbpm.group.javaeye.com/group/topic/2707
? 任務的管理

1,Oracle數(shù)據(jù)庫的位圖索引(Bitmap Index)確實是針對那些數(shù)值稀疏(low-cardinality，低基數(shù))的字段，但是還應記住的一點是，它是針對那些值不經(jīng)常改變的字段的。在實際應用中，如果某個字段的值需要頻繁更新，那么就不適合在它上面創(chuàng)建位圖索引。在位圖索引中，如果你更新或插入其中一條數(shù)值為N的記錄，那么相應表中數(shù)值為N的記錄（可能成百上千條）全部被Oracle鎖定，這就意味著其它用戶不能同時更新這些數(shù)值為N的記錄，其它用戶必須要等第一個用戶提交后，才能獲得鎖，更新或插入數(shù)據(jù)。
http://blog.ccidnet.com/blog-htm-do-showone-uid-4092-itemid-291252-type-blog.html

在我們的系統(tǒng)里，不僅不是在一個column上創(chuàng)建bitmap index，而是在多個column上聯(lián)合起來創(chuàng)建bitmap index，從而可以想見，幾乎等同于每個bitmap index entry對應的只有極少數(shù)的rowid，即只對應極少數(shù)的row，而且每個bitmap都要創(chuàng)建一個或多個bitmap segment，相應的，DML操作可能需要頻繁的lock很多rows，影響并發(fā)性（影響也需要修改同樣bitmap entry的用戶），同時，由于pctfree等存儲參數(shù)影響index空間的分配及管理，和由于數(shù)據(jù)操作導致物理地址更改從而修改index entry，擴展，鏈接bitmap index entry，頻繁修改導致的磁盤碎片，block分配鏈接等。這是空間增長和系統(tǒng)性能下降的部分原因。

bitmap主要用于數(shù)據(jù)倉庫，table有大量的數(shù)據(jù)并且列上基數(shù)很小（一般是column的distinct values占rows總數(shù)的1%以下，或重復出現(xiàn)超過100次以上，Oracle建議此時才可以把該column列為創(chuàng)建bitmap index的侯選字段），同時，還由于數(shù)據(jù)倉庫上并行訪問的事務非常少。bitmap index并不適用于OLTP業(yè)務，OLTP一般都是有大量的并發(fā)事務來修改同樣的數(shù)據(jù)。bitmap主要就是設計來為數(shù)據(jù)倉庫服務的，即應用于低基數(shù)超 級大數(shù)據(jù)量查詢服務，而且只用在where clause里包含and ,or,not,或equality queries（比如在and和or條件的查詢，在把bit轉(zhuǎn)換成rowid以前，就能很快的得到相應的boolean操作）。
http://bigboar.itpub.net/post/8411/225321

2,位圖索引占用的空間很大.一個466萬行記錄的只有兩個字段的表，占用空間約 88M,在該兩個字段上建有一個位圖索引，這個位圖索引占用空間約168M
http://bigboar.itpub.net/post/8411/225321

查看各個表(包括索引)占用空間大小的sql:
Select Segment_Name,Sum(bytes)/1024/1024 From User_Extents Group By Segment_Name

http://space.itpub.net/193161/viewspace-50292
http://www.ixdba.com/html/y2007/m05/102-bitmap-index-deadlock.html

3，Oracle強烈建立，任何一個應用程序的庫表至少需要創(chuàng)建兩個表空間，其中之一用于存儲表數(shù)據(jù)，而另一個用于存儲表索引數(shù)據(jù)。因為如果將表數(shù)據(jù)和索引數(shù) 據(jù)放在一起，表數(shù)據(jù)的I/O操作和索引的I/O操作將產(chǎn)生影響系統(tǒng)性能的I/O競爭，降低系統(tǒng)的響應效率。將表數(shù)據(jù)和索引數(shù)據(jù)存放在不同的表空間中（如一 個為APP_DATA，另一個為APP_IDX），并在物理層面將這兩個表空間的數(shù)據(jù)文件放在不同的物理磁盤上，就可以避免這種競爭了。
擁有獨立的表空間，就意味著可以獨立地為表數(shù)據(jù)和索引數(shù)據(jù)提供獨立的物理存儲參數(shù)，而不會發(fā)生相互影響，畢竟表數(shù)據(jù)和索引數(shù)據(jù)擁有不同的特性，而這些特性又直接影響了物理存儲參數(shù)的設定。
此外，表數(shù)據(jù)和索引數(shù)據(jù)獨立存儲，還會帶來數(shù)據(jù)管理和維護上的方面。如你在遷移一個業(yè)務數(shù)據(jù)庫時，為了降低數(shù)據(jù)大小，可以只遷出表數(shù)據(jù)的表空間，在目標數(shù)據(jù)庫中通過重建索引的方式就可以生成索引數(shù)據(jù)了。
http://blog.ccidnet.com/blog-htm-do-showone-uid-19759-itemid-341747-type-blog.html

4，B-Tree索引即normal普通索引

在jBPM中，任務的分配有兩種模式：

1. 推（Push）模式??? 在這種模式下，系統(tǒng)計算出應該由哪個參與者(actor)完成當前任務(task)，然后直接將此task送到該actor的任務列表中(tasklist)；
2. 拉（Pull）模式??? 在這種模式下，系統(tǒng)首先計算出應該由哪個參與者池(pool of actors)完成當任務，并將該任務送入相應的任務池中；然后，再由參與者池中的任一人將任務拉到自己的任務列表中。

參與者池與角色、用戶組的差異

一般的應用中，角色與用戶組的概念比較常見，而參與者池則不常見。

針對一個Task一般會有多個可能的操作，而不同的角色有可能有權限進行其中的一部分或全部操作。所以，不同角色有可能屬于相同的參與者池，一個角色也有可能被加入到多個參與者池中。

一 般用戶組是按組織架構(gòu)進行劃分的，在同一個用戶組可能會有多個不同的角色，或者具有不級別的權限。即使將同一角色、具有同一級別權限的用戶劃分為一組，也 不能回避具有更高級別權限的用戶操作低級別工作任務項的情形。另一方面，在Multi-Entity架構(gòu)下，也存在跨Entity操作的情形。

總而言之，參與者池是區(qū)別于按角色、按組織進行劃分的、一種特別的用戶分組方法。換言之，參與者池其實也是可以預先定義的。

何時進行任務分配計算

既然參與者池是可以預見的，那么在“拉模式”下，何時進行任務分配計算呢？

毫無疑問，在工作流系統(tǒng)中，計算是在任務狀態(tài)轉(zhuǎn)換時自動完成的。（當然，相對于應用的事務提交，工作流的這些操作都可以是異步完成的。）

因些，“拉”的含義，不是在用戶刷新任務列表時才去計算他/她的所有工作項；恰恰相反，無論是“拉”或是“推”，工作流系統(tǒng)其實都預先計算好了參與者的任務列表或可以從中挑選任務的“任務池”。

jBPM參與者池的數(shù)據(jù)庫設計

jbpm_taskinstance與jbpm_pooledactor是典型的“多對多”的關系，中間通過jbpm_taskactorpool拆分成兩個“一對多”。
原文:http://dayubian.spaces.live.com/blog/cns!9E5A349DF844201E!365.entry

可伸縮性最佳實踐：來自eBay的經(jīng)驗

為什么對客戶需求的理解經(jīng)常變動？那是因為沒有抓住問題的本質(zhì)，沒有分析出需求對應的領域模型
http://www.javaeye.com/topic/214489?page=2