HF EJB "Sharpen your pencil p. 497"

[Philippe Maquet]

Hi everybody,
I have two questions :
1) Of the six transaction attributes, which one (or ones) must NOT be used by a bean that calls getRollbackOnly() or setRollbackOnly()?
Answer = Never
In the specs p. 180, I read : "The getRollbackOnly and setRollbackOnly methods of the EntityContext interface should be used only in the enterprise bean methods that execute in the context of a transaction. The Container must throw the java.lang.IllegalStateException if the methods are invoked while the instance is not associated with a transaction."
So I had added to Never : Supported and NotSupported
Am I right ? If not, why ?
4) Of the six transaction attributes, three of them can be dangerous, with
one in particular being EXTREMELY risky. Keeping in mind that the Bean Provider is NOT the one who specifies the attributes for the bean�s methods, which of the six is potentially the most dangerous?
Answer = Mandatory and NotSupported are dangerous, because they throw exceptions, but Supports is the riskiest.... because it means at runtime you don�t know whether it will run in a transaction or not.
NotSupported doesn't throw exceptions. I would have written "Never" instead. Is this correct ?
Best,
Phil.

[Philippe Maquet]

Anybody to validate (or invalidate) my previous post ?
Thanks in advance.
Phil.

[Kanth Kris]

To your question #4: "NotSupported" doesn't throw any exception but I think it is equally dangerous as "Never" because the bean method would run without any TX* context [suspends the current TX].
On a side note, here is how I remember some of the transaction attributes:
* M & N (mandatory and never) throw exceptions.
* The two longest attributes [RequiresNew & NotSupported] suspend the existing TX.
* To distinguish between present and past tense: red [for Required) and nod (NotSupported). Their counterparts are present tense: RequiresNew and Supports. [or you can use Kathy's traditional rhyme "Roses are red...I simply nod"]
thanks
Kanth
PS: TX is transaction, not Texas [for some cowboys and cowgirls]

[Philippe Maquet]

Hi Kanth,
Thanks for your reply.

To your question #4: "NotSupported" doesn't throw any exception but I think it is equally dangerous as "Never" because the bean method would run without any TX* context [suspends the current TX].

So you agree that :
1. "Never" is more dangerous than "NotSupported", and even more than "Supports" ?
2. Kathy's answer is incorrect ("Mandatory and NotSupported are dangerous, because they throw exceptions") ?
Now what about #1 ?
Best,
Phil.

[Bharat Ruparel]

Hello Phil,
This is Bharat. I think that it all depends on what is it that you are trying to do!
For example, we have a rather large WebLogic 6.1 application that uses an Entity Bean to read and cache the configuration data that is used heavily by other Beans and java programs. Weblogic allows us to deploy it as a Read Only Bean. We did that and have been experiencing sporadic performance problems for quite some time. Upon doing extensive load-testing and performance monitoring, we found that this particular Bean was showing very high lock-waiting count as compared to other beans. This was quite a surprise to us since we assumed that the Read Only declaration, which is WebLogic specific, should allow us to use this Bean without any locking since it caches read only data. Not true, Ed Roman's book, Mastering Enterprise Beans, clearly shows that for a Read Only Bean, the transaction attribute should either be Not Supported or Never.
Since we have other Beans calling this Bean that have a transactional context, we cannot use Never which will throw an exception. Therefore, we declared it as Not Supported. Preliminarly testing shows a lock waiter count of zero as it should be. Heavy duty load testing remains after making this deployment change.
This experience leads me to believe that almost all of the transactional attributes are needed at one point or the other. Some are more heavily used that the others though.
However, I agree with you that Never (and may be Mandatory?) attributes probably are not as useful?
Hope this helps.
Regards.
Bharat

[Philippe Maquet]

Hi Bharat,
Thank you for those real-world / real-life useful explanations !
Best,
Phil.

[seemapanth Joshi]

I have been thinking about the point #4 made in this sharpen exercise and looking around for some answers and so am pulling this thread back again because I saw total of 9 threads that talked about the issue and I am still not sure what can be considered definitely as the correct analysis. What Philippe Maquet mentioned in this topic is true or not?

Philippe Maquet:

1) Of the six transaction attributes, which one (or ones) must NOT be used by a bean that calls getRollbackOnly() or setRollbackOnly()?

Answer = Never

In the specs p. 180, I read : "The getRollbackOnly and setRollbackOnly methods of the EntityContext interface should be used only in the enterprise bean methods that execute in the context of a transaction. The Container must throw the java.lang.IllegalStateException if the methods are invoked while the instance is not associated with a transaction."

So I had added to Never : Supported and NotSupported

For the point #4, one would deduce that NotSupported indeed is the riskiest from Bharat Ruparel's great real-life example.

I wish I could get a raise of hands to just get on the level with what everyone thinks about this issue.
[ August 23, 2005: Message edited by: seemapanth Joshi ]