由於bkail聲明@Stateless bean的池化語義是特定於供應商的。也就是說在EJB 3.1中我們添加了@AccessTimeout
註釋,該註釋可以用於豆類或@Stateless
,@Stateful
或@Singleton
bean的方法。
@AccessTimeout
在一般意義上,這批註便攜指定了多久,如果等待條件與併發訪問時主叫方將等待。具體到每個bean的類型,等待何時將發生的條件:
@Singleton
- 一個@Lock(WRITE)
方法被調用並且正在使用容器管理併發。所有方法默認爲@Lock(WRITE)
。
@Stateful
- 調用實例的任何方法併發生第二次調用。或者@Stateful bean在一個事務中,調用者從該事務之外調用它。
@Stateless
- 池中沒有實例可用。但是,正如所指出的那樣,彙集語義,如果有的話,不包括在規範中。如果供應商的池語義確實包含等待條件,則應該使用@AccessTimeout。
用法
的@AccessTimeout
是簡單地圍繞java.util.concurrent
API中常用long
和TimeUnit
元組一個方便的包裝。
import java.util.concurrent.TimeUnit;
@Target({METHOD, TYPE})
@Retention(RUNTIME)
public @interface AccessTimeout {
long value();
TimeUnit unit() default TimeUnit.MILLISECONDS;
}
當一個bean類或方法明確設置,它有三個可能的含義:
@AccessTimeout(-1)
- 從不超時,等待,只要它需要。可能永遠。
@AccessTimeout(0)
- 永不等待。如果發生等待情況,立即拋出ConcurrentAccessException
。
@AccessTimout(30, TimeUnit.SECONDS)
- 如果發生等待情況,最多等待30秒。在此之後,扔ConcurrentAccessTimeoutExcpetion
沒有標準的默認
注意,value
屬性沒有缺省。這是故意的,意在表明如果@AccessTimeout
未明確使用,您獲得的行爲是特定於供應商的行爲。
一些供應商會等待預先配置的時間並拋出javax.ejb.ConcurrentAccessException
,一些供應商會立即拋出它。當我們定義這個註釋時,很明顯,我們所有的供應商都在做一些不同的事情,強制執行默認會導致現有應用程序出現問題。
在類似的說明中,在EJB 3.0之前,沒有默認的事務屬性,它對每個供應商都不同。謝天謝地,EJB 3.0已經不同了,我們終於可以說:「對於EJB 3.0 bean,默認值是必需的。」
這是所有供應商特定的。你正在使用哪個EJB容器?我建議在問題中添加「glassfish」,「openejb」,「weblogic」,「websphere」等標籤。 – 2011-06-16 22:06:44