avatar
Singleton Session Bean# Java - 爪哇娇娃
t*e
1
一个简单的 demo, 就这一个 class, as a singleton session bean. 然后就是 JSF
中直接对它的引用。 分别点击 Increment, A and B 可分别加 1. 如果去掉
Singleton annotation, 则 click 无效, counter 不增加,A & B 的值一直呆在 1
不变.
这是什么原理? 另外,去掉 @Singleton, Counter 是不是就变成了一个 stateful
session bean.

Counter A#{counter.a}

avatar
t*e
2
According to the specification:
A singleton session bean is instantiated once per application and exists for
the lifecycle of the application. Singleton session beans are designed for
circumstances in which a single enterprise bean instance is shared across
and concurrently accessed by clients.
我测试时就一个 session, 一个 browser, single request, single client, 没法解
释上面的行为?
avatar
z*e
3
你居然在学ejb,牛逼
singleton就是整个jvm就这一个
然后所有threads对它的访问都是并发并且不加以控制的
你这里i++好像我记得不是原子操作
所以你如果要挨个incre需要控制一下并发
去掉singleton应该是stateless
这样每次访问都是单独隔离的一个ejb来接待
avatar
t*e
4
这是 Wildfly 8 里面的例子,还是最新的东西。是,需要并发控制,上面的 code, 等
同于下面的 version. 默认情况下,容器自动加写锁。
session bean 的概念,包括 stateful, stateless, singleton 还是要搞董吧。在同
一个页面,同一个 browser session, 同一个 client, 每单击 “Increment” 一次,
难道这属于多客户的并发访问? JEE 7 Doc:
"A singleton session bean is instantiated once per application and exists
for the lifecycle of the application. Singleton session beans are designed
for circumstances in which a single enterprise bean instance is shared
across and concurrently accessed by clients."
在 JEE 里,如果要实现这种 counter, 不用 singleton bean, 还有什么替代方案?
@ConcurrencyManagement(ConcurrencyManagementType.CONTAINER)
@Singleton
@Named
public class Counter {
private int a = 1;
private int b = 1;
@Lock(LockType.WRITE)
public void incrementA() {
a++;
}
@Lock(LockType.WRITE)
public void incrementB() {
b++;
}
@Lock(LockType.WRITE)
public int getA() {
return a;
}
@Lock(LockType.WRITE)
public int getB() {
return b;
}
}

【在 z****e 的大作中提到】
: 你居然在学ejb,牛逼
: singleton就是整个jvm就这一个
: 然后所有threads对它的访问都是并发并且不加以控制的
: 你这里i++好像我记得不是原子操作
: 所以你如果要挨个incre需要控制一下并发
: 去掉singleton应该是stateless
: 这样每次访问都是单独隔离的一个ejb来接待

avatar
t*e
5
另外,stateless bean, 好像必须有 @stateless annotation 才算。

【在 z****e 的大作中提到】
: 你居然在学ejb,牛逼
: singleton就是整个jvm就这一个
: 然后所有threads对它的访问都是并发并且不加以控制的
: 你这里i++好像我记得不是原子操作
: 所以你如果要挨个incre需要控制一下并发
: 去掉singleton应该是stateless
: 这样每次访问都是单独隔离的一个ejb来接待

avatar
z*e
6
搞懂不难,但是很多人搞不懂ejb
我也不知道为啥,可能是ejb2的年代有些over kill了
你要写一个计数器,可以押给db去做
找个内存db就好了,或者做成async的thread
不过感觉没有必要,就singleton就是了,然后加上并发控制

,

【在 t*********e 的大作中提到】
: 这是 Wildfly 8 里面的例子,还是最新的东西。是,需要并发控制,上面的 code, 等
: 同于下面的 version. 默认情况下,容器自动加写锁。
: session bean 的概念,包括 stateful, stateless, singleton 还是要搞董吧。在同
: 一个页面,同一个 browser session, 同一个 client, 每单击 “Increment” 一次,
: 难道这属于多客户的并发访问? JEE 7 Doc:
: "A singleton session bean is instantiated once per application and exists
: for the lifecycle of the application. Singleton session beans are designed
: for circumstances in which a single enterprise bean instance is shared
: across and concurrently accessed by clients."
: 在 JEE 里,如果要实现这种 counter, 不用 singleton bean, 还有什么替代方案?

avatar
z*e
7
太久没用了,我不太记得了
应该是default就是stateless
不确定,或者如果什么都不加就不是ejb
如果你用了spring那种方式的话
用beans.xml,那default就是singleton

【在 t*********e 的大作中提到】
: 另外,stateless bean, 好像必须有 @stateless annotation 才算。
avatar
t*e
8
在同一个页面,就是是同一个用户连续单击一个 button, 如果去掉 @singleton, 每次
就会产生一个不同的 bean instance. 也就是说,即使同一个用户,先后操作同一个事
件,也会被 container 认为是多任务的并发操作,因而产生多个 instance, 对应不同
的客户需求。像 counter 这样的多用户共享的对象,就要用 singleton,以保证在同一
个对象内操作。
问题是,浏览器里面的 session 的概念是不是和服务器里面 (尤其是 EJB) session
概念不一样。由于同一个页面,连续单击一个 button, 浏览器里面肯定是一个
session, 但是在 Web 容器里面就被看成了多用户,多 session 的操作(至少是潜在
的). 可以这样认为不?

【在 z****e 的大作中提到】
: 太久没用了,我不太记得了
: 应该是default就是stateless
: 不确定,或者如果什么都不加就不是ejb
: 如果你用了spring那种方式的话
: 用beans.xml,那default就是singleton

avatar
t*e
9
哦,好像是跟 bean 的应用 scope 有关。当去掉 @singleton 后,它变成了 @
Dependent scope, by default. 每次单击,是一个新的请求,产生一个新的 bean
instance, 跟 RequestSope 产生的效果差不多。
ApplicationScoped Specifies that a bean is application scoped.
ConversationScoped Specifies that a bean is conversation scoped.
Dependent Specifies that a bean belongs to the dependent pseudo-scope.
NormalScope Specifies that an annotation type is a normal scope type.
RequestScoped Specifies that a bean is request scoped.
SessionScoped Specifies that a bean is session scoped.
Session Scope: The session scope persists from the time that a session is
established until session termination. A session terminates if the web
application invokes the invalidate method on the HttpSession object, or if
it times out.
RequestScope: The request scope is short-lived. It starts when an HTTP
request is submitted and ends after the response is sent back to the client.
If you place a managed bean into request scope, a new instance is created
with each request. It is worth considering request scope if you are
concerned about the cost of session scope storage.
ApplicationScope: The application scope persists for the entire duration of
the web application. That scope is shared among all requests and all
sessions. You place managed beans into the application scope if a single
bean should be shared among all instances of a web application. The bean is
constructed when it is first requested by any user of the application, and
it stays alive until the web application is removed from the application
server.
avatar
g*g
10
stateful session bean没啥大用,是scale的大忌。单节点的时候看着很方便,等你量
上来了,单节点撑不住,立马面临程序重写。同样的需求,你把它扔进一个关系数据库
,不就简单多了。
avatar
t*e
11
像用户注册,用户 shopping, 这类简单,常规的,是不是需要 stateful?
刚开始,还没什么感觉

【在 g*****g 的大作中提到】
: stateful session bean没啥大用,是scale的大忌。单节点的时候看着很方便,等你量
: 上来了,单节点撑不住,立马面临程序重写。同样的需求,你把它扔进一个关系数据库
: ,不就简单多了。

avatar
g*g
12
Session跟stateful是两码事。

【在 t*********e 的大作中提到】
: 像用户注册,用户 shopping, 这类简单,常规的,是不是需要 stateful?
: 刚开始,还没什么感觉

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。