[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jfriends-ml 10237] Re: Effective Java 読書会 3 回目議事録
高橋(智)です。
[ EJB Design Patterns: Advanced Patterns, Processes, and Idioms ]
http://www.amazon.co.jp/exec/obidos/ASIN/0471208310/qid=1029772574/
sr=1-1/ref=sr_1_2_1/250-3437232-6765015
によりますと...
======上記の本より引用========================================
P201
Using Java Singletons Is OK
If They're Used Correctly
-------------------------------------------------------
There is a lot of fear, uncertainly, and doubt(FUD) about the role of
singletons in EJB. The original Singleton pattern(Gamma, et al., 1995),
suggests creating a Java class that contains a static instance of itself,
so that only one instance of the class will run in application. The EJB
spec states that EJBs should not use static fields, nor should they use
synchronization primitives(such as the 'synchronized' keyword).
Many developers have incorrectly assumed that this means that an EJB cannot
call out to a singleton, since the singleton itself makes use of a static
field and the 'synchronized' keword.
This assumption is false. There is nothing wrong with using a Singleton
class, as long as developers DO NOT use it in read-write fashion, in which
case EJB threads calling in may need to be blocked. It is this type of
behavior that the spec is trying to protect against. Using a singleton
for read-only behavior, or any type of service that can allow EJBs to
access it independently of one another is fine.
One caveat with using Java singletons is that it is impossible to create
a singleton in the classic sense---one instance of an object per application.
At the very least, any singletons used will have one copy per server JVM,
and usually will have one instance per class loader(each developed ejb-jar
will have its own separate class loader and its own Singleton if it uses one).
Use a Java Singleton class when you would like to create a nonblocking
service in which you do not mind having a few copies of the singleton in-
memory in the same VM, but do not want the pooling and memory overhead of
implementing the service as a stateless session bean. For example, a primary
key generator(such as the UUID for EJB or Sequence Block patterns) would
provide a lighter-weight and more efficient implementation choice than a
stateless session bean.
======上記の本より引用========================================
だそうです。
ご参考までに。
--
高橋智宏
Java読書会( http://www.t3-jpn.com/bof/ )
T3-Japan( http://www.t3-jpn.com/ )
TAKAHASHI Toru wrote:
>
> 高橋(徹)です。
>
> "Murayama Toshikiyo <murayama@xxxxxxxxxxxxx>"さんは書きました：
> > 話は変わりますが，クラスローダーが異なる場合は名前空間が異なる
> > ので，同じ名前／同じ実装でも異なるクラスとして扱われると思い
> > ますが，これは「たまたま名前が同じだけの別のクラス」で，実装が
> > 同じ場合はその特殊な例と考えるべきなんじゃないでしょうか？
> タイプセーフEnumが複数のクラスローダで利用される場合の問題点が
> 下記記事に載っています。サンプルコードもあります。
> "Beware of Java typesafe enumerations"
> http://www.javaworld.com/javaworld/javatips/jw-javatip122.html?
>
> 記事によれば、EJB/JSPを例に問題が生じるケースを説明しています。
> ・あるEJBが別のEJBのメソッドを起動する場合、EJBが別々の配布JARに
> 収められていると、異なるクラスローダーからロードされるかもしれな
> い。双方のJARにEnumクラスが含まれており、それぞれでEnumクラスが
> ロードされていたときに、EJB間でEnumクラスを含むデータをマーシャ
> リングなしに交換すると問題が起きる。
> （JSPの方は省略）
snip