示例或用途解释EJB事务属性的案例
EJB事务属性(和注释)有一些很好的解释,例如, OpenEJB 。
但有时当我试图用一些没有使用过很多交易资源的人来掩盖这一点时,我看到他们的眼睛开始茫然。
所以我的问题 – 你如何向祖母解释EJB交易属性?
- 需要
- RequiresNew
- 强制性
- 不支持
- 支持
- 决不
我在想一个人为的例子,类比或简洁的现实用例会有所帮助。
您可以根据协作来考虑它们。 假设你是一名厨师,你可以和十几个烤箱一起工作。 你需要烤一些蛋糕。 对于这个例子, 你是被调用的方法, 烤箱是交易,你的老板是调用者。
- 要求 :如果你的老板告诉你在不告诉你使用什么烤箱的情况下烤一些蛋糕,你只需要选择一个。 最后,你关闭烤箱,确保没有其他人可以使用它。
- 需要新的 :你总是在你选择的免费烤箱上烤蛋糕。 如果你正在烘烤一些蛋糕的过程中,而你的老板告诉你再烤一批,你就会打断当前的烘焙过程,去新烤箱里烤一些蛋糕,继续烘烤旧烤饼。
- 强制性的 :你是一个愚蠢的厨师。 你的老板总是要告诉你你必须使用什么烤箱。 如果你的老板不告诉你使用什么烤箱,你会大喊“愚蠢!”。
- NotSupported :把它想象成做一个不需要烤箱的甜点。 如果你正在烘烤一些蛋糕的中间,你停止,创建甜点,并恢复蛋糕烘烤。
- 支持 :这更适合厨师的助手。 你是帮助者。 如果主厨要你用烤箱X烤蛋糕,你就是这么做的。 如果他要你做甜点,你就是这么做的。 与其他问题的主要区别在于,您从不提出任何问题,也不会选择做任何事情。 你只需按照订单。
- 永远不会 :这是另一个愚蠢的厨师。 如果你的老板在你正在烘烤蛋糕的过程中要求你做一个甜点,你会大喊大叫并说“我放弃了!”。 没有蛋糕被烘烤。 因此,你的老板必须要小心,只要你不烘烤任何蛋糕,就要求你烤一些蛋糕。
希望有所帮助。
我认为根据容器与调用者与EJB方法的交互作为一个真正的监视器来考虑这一点是有道理的…所以我想在各种不同的场景中使用一个保镖隐喻 。
有关事务属性的详细说明/概述,请参阅此页面 。
必需(必需@TransactionAttribute)
夜店
出现在俱乐部,需要一张入场券。 如果你没有,它会在门口给你(购买?)。
交易是TICKET。
容器是BOUNCER。
需要新的(REQUIRES_NEW @TransactionAttribute)
喜剧俱乐部,1饮料至少,没有重新进入
出现在俱乐部,没有外面的食物/饮料,你必须把它们留在门口。 每次离开并重新进入时,您必须购买至少1杯饮料。
交易是DRINK。
容器是BOUNCER。
暂停交易是在门口离开。
支持(SUPPORTS @TransactionAttribute)
家庭聚会
出现在派对上,允许饮酒。 如果你有自己的酒,我们会让你进去,如果你不这样做,我们也会让你进去。
交易是ALCOHOL。
容器是主机。
强制性的(强制性@TransactionAttribute)
仅邀请派对
出现在派对上,需要一个邀请才能进入:如果你没有,并试图进入,保镖会打电话给当局。
交易是邀请。
容器是主机。
抛出一个例外就是致电当局。
不支持(NOT_SUPPORTED @TransactionAttribute)
音乐会,相机是禁止的。
出现在音乐会上,相机是禁止的。 你可以把它留在门口,当你离开时捡起它。
交易是CAMERA。
容器是DOORMAN。
暂停交易是在门口离开。
从不(从不@TransactionAttribute)
高中舞蹈
出现在舞会上,禁止饮酒。 如果你试图接受它并被抓住,那么监护人就会打电话给当局。
交易是ALCOHOL。
容器是CHAPERONE。 抛出一个例外就是致电当局。
- 使用本地EJB,在同一个Container但不同的耳朵
- SessionContext.getBusinessObject()的返回值与bean中使用的’this’关键字有何不同?
- @PostConstruct中的CDI参数
- javax.naming.NoInitialContextException:无法实例化类:
- 在注入点使用限定符的类型的不满意依赖(使用带有CDI的@Stateful EJB)
- 如何在群集环境中使用javax.ejb.Singleton?
- 将EJB3注入基于注释的JSF2 Backing bean导致javax.naming.NameNotFoundException:
- 无法从Java SE客户端访问EJB – 查找失败错误
- 两个相关JPA实体之间的接口