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
