2008年12月4日
#
1. Remote
Method Invocation (RMI)
2. Hessian
3. Burlap
4. HTTP invoker
5. EJB
6. JAX-RPC
7. JMX
zz from http://marakana.com/forums/tomcat/general/106.html
Valve and Filter:
"Valve" is Tomcat
specific notion, and they get applied at a higher level than anything in a specific webapp. Also, they work only in Tomcat.
"Filter" is a Servlet Specification notion and should work in any compliant servlet container. They get applied at a lower level than all of Tomcat's
Valves.
However, consider also the division between your application and the application
server. Think whether the feature you're planning is part of your application, or is it rather a generic feature of the application server, which could have uses in other applications as well. This would be the correct criteria to decide between Valve and Filter.
Order for filter: The order in which they are
defined matters. The container will execute the filters in the order
in which they are defined.
Use one single table "blank_fields" for both A and B. "blank_fields" has fields: 'ref_id', 'blank_field', 'type'. 'type' is used to identify which entity the record belongs to. Use 'type' + 'ref_id' to specify the collection of elements for one entity.
@Entity
@Table(name = "table_a")
public class A {
private Set<BlankField> blankFields = new HashSet<BlankField>();
@CollectionOfElements
@Fetch(FetchMode.SUBSELECT)
@Enumerated(EnumType.ORDINAL)
@JoinTable(name = "blank_fields", joinColumns = { @JoinColumn(name = "ref_id") })
@Cascade(value = org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
@Column(name = "blank_field", nullable = false)
@SQLInsert(sql = "INSERT INTO blank_fields(ref_id, blank_field, type) VALUES(?,?,0)")
@Where(clause = "type=0")
public Set<BlankField> getBlankFields() { // BlankField is an enum
return blankFields;
}
@SuppressWarnings("unused")
private void setBlankFields(Set<BlankField> blankFields) {
this.blankFields = blankFields;
}
} // End B
@Entity
@Table(name = "table_b")
public class B {
private Set<BlankField> blankFields = new HashSet<BlankField>();
@CollectionOfElements
@Fetch(FetchMode.SUBSELECT)
@Enumerated(EnumType.ORDINAL)
@JoinTable(name = "blank_fields", joinColumns = { @JoinColumn(name = "ref_id") })
@Cascade(value = org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
@Column(name = "blank_field", nullable = false)
@SQLInsert(sql = "INSERT INTO blank_fields(ref_id, blank_field, type) VALUES(?,?,1)") // used for insert
@Where(clause = "type=1") // used for query, if not @CollectionOfElements, such as @OneToMany, use @WhereJoinTable instead
public Set<BlankField> getBlankFields() {
return blankFields;
}
@SuppressWarnings("unused")
private void setBlankFields(Set<BlankField> blankFields) {
this.blankFields = blankFields;
}
}
當然還有其他的方式來實現上面的需求，上面采用的單表來記錄不同實體的associations（這兒是CollectionOfElements，并且返回的是Set<Enum>，不是Set<Embeddable>)，然后用'type'來區分不同的實體，這樣做的好處是：數據庫冗余少，易于擴展，對于新的實體，只需加一個type值，而不需更改數據庫表結構。另外一種采用單表的方式是為每個實體增加新的字段，如"blank_fields": 'a_id', 'b_id', 'blank_field', a_id reference table_a (id), b_id reference table_b (id). 這樣在映射的時候更簡單，
對于A，映射為
@JoinTable(name = "blank_fields", joinColumns = { @JoinColumn(name = "a_id") })
對于B，映射為
@JoinTable(name = "blank_fields", joinColumns = { @JoinColumn(name = "b_id") })
這樣作的缺點是：帶來了數據庫冗余，對于blank_fields來講，任一條記錄，a_id和b_id中只有一個不為null。當多個實體共用這個表時，用上面的方法更合理，如果共用實體不多時，這種方法更方便。
The case to use One Hibernate Session Multiple Transactions:
each transaction would NOT affect others.
i.e., open multiple transactions on the same session, even though one transaction rolls back, other transactions can be committed. If one action fails, others should fail too, then we should use one transaction for all actions.
Note:
A rollback with a single Session will lead to that Session being cleared (through "Session.clear()").
So do lazy collections still work if the session is cleared? =>Not of any objects that you loaded up until the rollback. Only for new objects loaded afterwards.
We should load necessary objects to session for each transactional action to avoid LazyInitializationException, even if those objects are loaded before other forward transactional actions, since forward action may be rolled back and clear the session.
BTW, Hibernate Session.merge() is different with Session.update() by:
Item item2 = session.merge(item);
item2 == item; // false, item - DETACHED, item2 - PERSIST
session.update(item); // no return value, make item PERSIST
發生這種異常的case:
@Transactional
public void foo() {
try{
bar();
} catch (RuntimeException re) {
// caught but not throw further
}
}
@Transactional
public void bar() {
}
如果foo在調用bar的時候，bar拋出RuntimeException，Spring在bar return時將Transactional標記為Rollback only， 而foo捕獲了bar的RuntimeException，所以Spring將會commit foo的事務，但是foo和bar使用的是同一事務，因此在commit foo事務時，將會拋出UnexpectedRollbackException。注意：如果foo和bar在同一class中，不會出現這種情況，因為：
Since this mechanism is based on proxies, only 'external' method calls coming in through the proxy will be intercepted. This means that 'self-invocation', i.e. a method within the target object calling some other method of the target object, won't lead to an actual transaction at runtime even if the invoked method is marked with @Transactional!
可以通過配置log4j來debug Spring事務獲取情況：
To delve more into it I would turn up your log4j logging to debug and also look at what ExerciseModuleController is doing at line 91, e.g.: add a logger for org.springframework.transaction
這周被Quartz折騰了一番。
我們知道，Quartz采用JobDataMap實現向Job實例傳送配置屬性，正如Quartz官方文檔說的那樣：
How can I provide properties/configuration for a Job instance? The key is the JobDataMap, which is part of the JobDetail object.
The JobDataMap can be used to hold any number of (serializable) objects
which you wish to have made available to the job instance when it
executes.
JobDataMap map ＝ context.getJobDetail().getJobDataMap();
我們通過map向Job實例傳送多個objects，其中有一個是個bean，一個是基本類型。對于scheduled triggers，我們要求bean對于所有的序列都不變，包括其屬性，而基本類型可以在Job運行過程中改變，并影響下一個序列。實際情況是，對于下個序列，bean的屬性被上次的修改了，而基本類型卻維持第一次put到Map里面的值。正好和我們要求的相反。
受bean的影響，以為map里面包含的都是更新的對象，即每個序列里面的JobDetail是同一個對象，但是基本類型的結果否認了這一點。回頭重新翻閱了下Quartz的文檔：
Now, some additional notes about a job's state data (aka JobDataMap): A
Job instance can be defined as "stateful" or "non-stateful".
Non-stateful jobs only have their JobDataMap stored at the time they
are added to the scheduler. This means that any changes made to the
contents of the job data map during execution of the job will be lost,
and will not seen by the job the next time it executes.
Job有兩個子接口：StatefulJob and InterruptableJob，我們繼承的是InterruptableJob，或許Quartz應該有個InterruptableStatefulJob。另外StatefulJob不支持并發執行，和我們的需求不匹配，我們有自己的同步控制，Job必須可以并發運行。
然后查看了Quartz的相關源碼：
// RAMJobStore.storeJob
public void storeJob(SchedulingContext ctxt, JobDetail newJob,
boolean replaceExisting) throws ObjectAlreadyExistsException {
JobWrapper jw = new JobWrapper((JobDetail)newJob.clone()); // clone a new one
.
jobsByFQN.put(jw.key, jw);
}
也就是說，store里面放的是初始JobDetail的克隆，在序列運行完時，只有StatefulJob才會更新store里面的JobDetail：
// RAMJobStore.triggeredJobComplete
public void triggeredJobComplete(SchedulingContext ctxt, Trigger trigger,
JobDetail jobDetail, int triggerInstCode) {
JobWrapper jw = (JobWrapper) jobsByFQN.get(jobKey);
if (jw != null) {
JobDetail jd = jw.jobDetail;
if (jd.isStateful()) {
JobDataMap newData = jobDetail.getJobDataMap();
if (newData != null) {
newData = (JobDataMap)newData.clone();
newData.clearDirtyFlag();
}
jd.setJobDataMap(newData); // set to new one
}
}
然后，每次序列運行時所用的JobDetail，是存放在Store里面的克隆。
// RAMJobStore.retrieveJob
public JobDetail retrieveJob(SchedulingContext ctxt, String jobName,
String groupName) {
JobWrapper jw = (JobWrapper) jobsByFQN.get(JobWrapper.getJobNameKey(
jobName, groupName));
return (jw != null) ? (JobDetail)jw.jobDetail.clone() : null; // clone a new
}
問題很清楚了，存放在Store里面的JobDetail是初始對象的克隆，然后每個序列所用的JobDetail， 是Store里面的克隆，只有Stateful job，Store里面的JobDetail才更新。
最有Quartz里面使用的clone():
// Shallow copy the jobDataMap. Note that this means that if a user
// modifies a value object in this map from the cloned Trigger
// they will also be modifying this Trigger.
if (jobDataMap != null) {
copy.jobDataMap = (JobDataMap)jobDataMap.clone();
}
所以對于前面所講的，修改bean的屬性，會影響所有clone的對象，因此，我們可以將基本類型封裝到一個bean里面，map里面存放的是bean，然后通過修改bean的屬性，來達到影響下一個序列的目的。
From:
Web application design: the REST of the story
Key points:
- HTTP is a very general, scalable protocol. While most people only
think of HTTP as including the GET and POST methods used by typical
interactive browsers, HTTP actually defines several other methods that
can be used to manipulate resources in a properly designed application
(PUT and DELETE, for instance). The HTTP methods provide the verbs in a web interaction.
- Servers are completely stateless. Everything necessary to service a request is included by the client in the request.
- All application resources are described by unique URIs. Performing
a GET on a given URI returns a representation of that resource's state
(typically an HTML page, but possibly something else like XML). The
state of a resource is changed by performing a POST or PUT to the
resource URI. Thus, URIs name the nouns in a web interaction.
剛剛看CCTV實話實說，很有感觸，義烏技術職業學院給人眼前一亮，尤其是他們副院長的一番言論。
技術職業學院非得要升本科，本科非要成清華，義烏職業技術學院副院長評價當前高校的現狀，定位嚴重有問題，技術職業學院應該培養應用型人才，而清華就應該培養研究性人才，兩種學校的定位不能一樣，培養方式，評判標準都應該不同，而現在大多數高校的定位都一樣，這是不對的。個人非常贊同這個觀點，其實，這個觀點也可以應用到我們這些剛開始工作的年輕人身上，消除浮躁，找準定位，然后沿著定位踏實做事，并且應該采取相應的評判標準，這個很重要。
1. RFC documents
2. SCEP operations
-
PKIOperation:
-
Certificate Enrollment - request: PKCSReq, response: PENDING, FAILURE, SUCCESS
-
Poll for Requester Initial Certificate - request: GetCertInitial, response: same as for PKCSReq
-
Certificate Access - request: GetCert, response: SUCCESS, FAILURE
-
CRL Access - request: GetCRL, response: raw DER encoded CRL
- Non-PKIOperation: clear HTTP Get
-
Get Certificate Authority Certificate - GetCACert, GetNextCACert, GetCACaps
-
Get Certificate Authority Certificate Chain - GetCACertChain
3. Request message formats for PKIOperation
- Common fields in all PKIOperation messages:
-
senderNonce
-
transactionID
- the SCEP message being transported(SCEP messages) -> encrypted using the public key of the recipient(Enveloped-data)
-> signed by one of certificates(Signed-data): the requester can generate a self-signed certificate, or the requester can use
a previously issued certificate, if the RA/CA supports the RENEWAL option.
- SCEP messages:
-
PKCSReq: PKCS#10
- GetCertInitial: messages for old versions of scep clients such as Sscep, AutoSscep, and Openscep, are different with draft-18
issuerAndSubject ::= SEQUENCE {
issuer Name,
subject Name
}
-
GetCert: an ASN.1 IssuerAndSerialNumber type, as specified in PKCS#7 Section 6.7
-
GetCRL: an ASN.1 IssuerAndSerialNumber type, as defined in PKCS#7 Section 6.7
--zz: http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1230261484567+28353475&threadId=1213960
Question:
We are planning to calculate the percentage of physical memory utilised as below:
System Page Size: 4Kbytes
Memory: 5343128K (1562428K) real, 13632356K (3504760K) virtual, 66088K free Page# 1/604
Now the formula goes as below:
(free memory / actual active real memory) * 100
(66088/1562428) * 100 = 4.22 %
Please let us know if its the correct formula .
Mainly we are interested in RAM percentage utilised
Reply 1:
Red Hat/Centos v 5 take spare ram and use it for a buffer cache.
100%
memory allocation is pretty meaningless because allocation is almost
always near 100%. The 2.6.x kernel permits rapid re-allocation of
buffer to other purposes eliminating a performance penalty that you see
on an OS like HP-UX
I'm not thrilled with your formula because
it includes swap(virtual memory). If you start digging too deep into
virtual memory, your system start paging processes from memory to disk
and back again and slows down badly.
The formula is however essentially correct.
Reply 2:
Here, a quick example from the machine under my desk:
Mem: 3849216k total, 3648280k used, 200936k free, 210960k buffers
Swap: 4194296k total, 64k used, 4194232k free, 2986460k cached
If
the value of 'Swap used' is up (i.e. hundreds of megabytes), then
you've got an issue, but as you can see, it's only 64k here.
Your formula for how much memory is used is something along the lines of this:
(Used - (Buffers + Cached) / Total) * 100 = Used-by-programs%
(Free + Buffers + Cached / Total) * 100 = Free%
.. Roughly ..
昨天遇到個非常奇怪的bug：更新了一下后臺的代碼，結果每次點擊頁面都會導致servlet方法調用兩次，從而頁面報錯（邏輯上不讓調兩次 ），我們的前臺采用gwt，servlet engine采用tomcat，debug的時候，斷點放在servlet所調用的method上，結果invoke兩次，由此斷定，前臺代碼的問題（有點武斷哦
），然后負責前臺的同事debugging前臺的代碼，噼里啪啦半天。。。，說是前臺好像沒有調兩次（之所以用好像，是debugging時部分代碼走兩次，部分走一次），而我當時的想法是，后臺怎么操作，也不至于讓servlet調用兩次吧，所以我個人就認定是前臺邏輯導致重復rpc調用（gwt），但是這個bug在這兩天才出現的，從svn的歷史記錄來看，前臺代碼在這兩天基本沒什么改變，同事只好從svn上一個version接一個version的check，最后確定出兩個相鄰的versions，前一個能用，后一個出bug，這時我隱約感覺到是后臺的問題，但是還是想不明白，后臺的邏輯怎么就能讓前臺重復調用，非常不解，沒辦法，在同事的建議下，在servlet的那個method上加上一條debug信息，做了兩次試驗，一次是完整的代碼，一次是把method中調用后臺的接口注釋掉，結果從日志上看出，前一次試驗debug信息打印了兩次，后一次試驗debug只打印了一次，此時，確定是后臺邏輯影響了前臺的調用（此時，覺得走彎路了，為什么不早點做這個試驗，其實確定是前臺還是后臺的問題，只需要做這樣一個簡單的試驗。。。）。接下來，我思考的就是到底是什么在作怪呢，對比svn上的兩個版本，只有兩處可能的改動，一處是將return改成throw exception, 一處是調用了Thread.currentThread.interrupt()，我一個感覺是后者，注掉這句后，一切OK，呵呵，慶幸沒有先嘗試前者，要不改動很大，。。。
剛剛看了gwt的源碼，還沒找到問題的根源，我的觀點是，thread接收到interrupt信號時，會重復發送rpc調用，（呵呵，還沒確定）。。。