Hi Guys, Find a question about Resource manager/Enterprise bean access. For example: 1. in ejbCreate(), Stateless bean cannot access Resource manager/Enterprise bean while stateful bean can access them; 2. in ejbActivate()/ejbPassivate(), Entity bean cannot access Resource manager/Enterprise bean while the stateful bean can access them.
This really bothers, greatly appreciate for you guys' suggestion.
1. in ejbCreate(), Stateless bean cannot access Resource manager/Enterprise bean while stateful bean can access them;
Basically, accessing resource managers and enterprise beans is disallowed in beans for which the container does not have a meaningful transaction context or client security context, i.e. when the client does not explicitely invoke a method on that bean.
The ejbCreate() method is invoked on a stateless session bean by the container but this call is not triggered by any client invocation, and thus, there cannot be any specific transaction or client security context. This is a different story with stateful session beans as they are created specifically for a given client when the latter invokes create() on the bean's home interface. Bottom line: a client is responsible for managing the lifecycle of stateful session beans but not of stateless session beans. As a result, a meaningful transaction and/or client security context can only exist when executing business methods of stateless session beans and when executing any kind of methods (except setSessionContext and afterCompletion) of stateful session beans.
2. in ejbActivate()/ejbPassivate(), Entity bean cannot access Resource manager/Enterprise bean while the stateful bean can access them.
Well, there seems to be some inconsistencies between the spec and the API because the spec states that ejbActivate() and ejbPassivate() may access resource managers and enterprise beans (and thus, that they are called within a meaningful transaction context) while the J2EE 1.3 APIs explicitely mention that ejbActivate() and ejbPassivate() are called within an unspecified transaction context. Also, if you look at Figure 9 in the EJB 2.0 specification, you'll see that activation and passivation is done when the container deems it necessary to do so, and thus, there cannot be any meaningful transaction context available at that time.
I'm gonna delve a little deeper in that issue and I'll try to come up with something more precise... In the meantime, if any of you guys have an idea, please let us know. Thanks
I have a delved a little into the transaction context issue and have found the following in the spec on page 76.
quote: --- A session bean�s newInstance, setSessionContext, ejbCreate, ejbRemove, ejbPassivate, ejbActivate, and afterCompletion methods are called with an unspecified transaction context. Refer to Subsection 17.6.5 for how the Container executes methods with an unspecified transaction context. ---
As far as I can read the spec there is no difference between stateless and stateful session beans regarding the unspecified transaction context of newInstance, setSessionContext, ejbCreate, ejbRemove, ejbPassivate, ejbActivate, and afterCompletion. Even though the client calling create on the home interface triggers the containers call to ejbCreate, the transaction context of ejbCreate of a stateful session is still unspecified. If you look in the spec on page 80 you can see that you are not allowed to call getRollbackOnly or setRollbackOnly in ejbCreate (and ejbRemove, ejbActivate and ejbPassivate) on the SessionContext of a stateful session bean because the transaction context is unspecified in these methods.
In the unspecified transaction context of a stateful session bean I think the bean provider can do things with resource managers and other enterprise beans with does not require an ongoing transaction. E.g. the bean provider can call other enterprise beans as long as the transaction attributes of the methods called is not set to Mandatory. The bean provider should not write could code which is expected to run in the same transaction context as the client initiating the call.
Kind regards Christian
posted 16 years ago
Valentin, Christian, Based on what you guys said, I didn't a summary for my question:
Rule of thumb: "accessing resource managers and enterprise beans depend upon whether container have a meaningful transaction or have client security context"
If this rule is right, then it can answer two of my question:
1) as for ejbCreate() of SessionBean (stateful and stateless), although the container only has unspecified transaction context in ejbCreate(), the container has client security context for stateful bean, so stateful bean can access resource manager/enterprise bean, while statleless bean cannot (no meanfingful tx, no client security context).
2) the same reason. ejbActivate()/ejbPassivate(), as for Entity Bean, it doesn't have meaningful transaction or client security context (Based on what Valentin saide: J2EE 1.3 APIs explicitely mention that ejbActivate() and ejbPassivate() are called within an unspecified transaction context), so it cannot access resource manager/enterprise bean.
If anyone can confirm this rule, then it really help us clarify a lot of stuff.
Knowing the tx context can help you decide wether you can do tx related operations like getRollgackOnly or getStatus and setRollbackOnly. But I don't think it is a good indicator on wether you can use resources and other beans. As you've said, for a stateful session bean's ejbCreate you are not in a tx context but you can still access resources. So I would say the transaction context will only allow you to determine when you can call get(set)RollbackOnly.
With ejbCreate on stateful session beans you can get an use UserTransaction for BMT. Well, that means you *could* start your own transaction right there and any access to resources or other beans would happen within that transaction context. I think it all goes back to the fact that stateful beans creation is directly linked with a client. The bean is created because a client wants to do something with it, now! So the bean is going to perform a task, it already has a mission in life. Maybe that's why you can get UserTransaction and use it.
When a stateless session bean is created it is just going to the pool and it could just sit there "for ever" without serving any client. So why would you want to call other beans or access resources when this lazy bean is created if it doesn't even know what it's going to do with its life.
I know this is all too high-level thinking and some people like technical reasons. But I believe it's really for logical reasons that things work the way they do and the container does the things it does. It's best to think logically than trying to come up with rules like "if you're in a tx you can access resources" which will always have exceptions. That's what I do anyway ...
As for passivation the important bit here is it means different things for stateful session bean and entity beans. For stateful beans it means the client is taking too long between calls and the container puts the bean to sleep. But the bean is still related to that client, it's still serving that client. It will eventually wake up and continue as if nothing ever happened (if the client finally makes a second call).
For entity beans passivation means the bean is going back to the pool. It is done being "Mr. Smith #28" and is getting ready to be just a bean again. Passivation is the end of the bean's performance as "Mr. Smith" while Activation is about the bean learning to be "Mr. Smith". That's all it is. Why do u want to contact other beans for that? Access resources? (you know ejbLoad is for getting Mr. Smith data from the db). If you can't do it it's probably because it doesn't make sense to do it and that's what we should try to understand ...
that's the way my twisted little brain works anyway ... hope it helps ... somehow ... cheers
posted 16 years ago
Lionel, I can't help claping my hands for your wonderful answer! Not only you answer this specific question, but also you did it in a very correct way:
It's best to think logically than trying to come up with rules like...
Yes, we should not only put ourselves into the detail specification or coding, sometimes, actually most times, we should consider why we need do or design program/software in this way. After all, EJB container is only a program running on the application server, so we can think in the high level -- what should be the correct design for it to handle the client's request. Then based on what you said, some situation for specific features do not make any sense in the correct high-level/design way, which really helps a lot for understanding so many abstract methods/exceptions/transactions of EJB.
Greatly appreicate your efforts!
If a regular clown is funny, then a larger clown would be funnier. Math. Verified by this tiny ad: