• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Access and meaningful transaction context

 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In HF page 354 it states that you can't access another beans methods or a resource manager without being in a 'meaningful transction context'. This makes perfect sense to me.
In a stateful session bean in ejbCreate (and ejbActivate, ejbPassivate and ejbRemove) you can access another bean and a resource manager so you should be in a 'meaningful transction context'. But in these methods you can't force the transction to rollback or find out if the tranaction has already been set to rollback.
How come you can't call these transaction methods even though you should be in a 'meaningful transction context'.
What am I missing here?
Best Regards /Magnus
[ December 20, 2003: Message edited by: Magnus Stattin ]
 
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Looks weird to me too. Any idea on this ? Thanks.
(BTW the second part of Magnus'post refers to p. 207 of HF EJB)
[ December 20, 2003: Message edited by: Philippe Maquet ]
 
Magnus Stattin
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is there anyone who has any thoughts or explanations for this? I can't make sense of it and that makes it much harder to learn.
Thanks in advance
/Magnus
[ December 23, 2003: Message edited by: Magnus Stattin ]
 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Same confusion here~~~
please answer...thanks thanks~~~~
 
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
This is my take on it.
As part of the bean having "beanness" it has to pass thru 3 things first - instantiation, setSessionContext and finally ejbCreate. It is only then when it moves into the "method-ready" state (e.g., be in a position to invoke your business methods).
According to the spec, page 81, Additional Restrictions. It says that getRollbackOnly and setRollbackOnly should only be used in [stateful] session bean methods (read business methods here) that execute in the context of a transtation. It is only when a bean is in "method-ready" state can it be involved as part of a transation. (e.g., from method-ready to method-ready-in-TX and not before.)
See also the diagram on page 77.
Hope this helps.
-=david=-
[ January 06, 2004: Message edited by: David Harrigan ]
 
Harvey Chan
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Actucally what i really confuse is .........
1. In both statful and statless session beans, the specification claimed that accessing resource manager and EJB is disallowed when there is no "meaningfull transaction context" OR "client Security Context".
(page 81 & page 91)
2. However, as you can see, stateful session bean allowed accessing the above objects in ejbCreate(), ejbRemove() and ......
But it was disallowed in statless session bean's ejbCreate() & ejbRemove().
3. I don't understand why statless and stateful session bean is different in this way. Does it means that statless session bean DON'T have "meaningful transaction context"? I am totally disagree about this because you can specify "transaction" method in statless session beans also. Am i correct?
So, what is the reason behind the differece of accessing ability of ejbCreate(), ejbRemove()... methods in statless and stateful session bean? Is it releated to the client security Context?
Yours
Harvey
 
Harvey Chan
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just come up in my mind, would it be like this?
1. Stateless session bean WON'T assigned any transaction when RUNNING methods like ejbCreate() and ejbRemove(). So, there would be NO meaningful transaction context when running these methods.
However, statless session bean WILL assign a transaction for ANY OTHER
business method. So, resources could be called.
2. Statful session bean WILL assigned transaction for methods like..ejbCreate(), ejbRemove(), ejbActivate().......
So that this methods call can use those resouces...

Am i correct??
Please correct my mistakes....
thanks so much
 
David Harrigan
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Perhaps you could clarify this, because I'm confused (easily happens). A stateful session bean, and a stateless session bean can only use transactions when they both are in a method-ready state. This state only happens when ejbCreate has completed and the bean is ready to service business method calls.
It doesn't make sense for it to service transactions in ejbRemove - since the bean is about to disappear, in ejbPassivate, since the bean is about to go to sleep (and could be there for sometime...), ejbActivate, since it isn't in a restored state ready to service (remember that these are only available to a stateful bean (except for ejbRemove)).
Stateless (and stateful) only have a meaningful transactional state when they are ready and willing and able to service clients and that is only in the method-ready state.
Ah, remember, when it says "access to" it means it can use. You can use the resource manager to give you a reference to a datasource, but you can't use that reference until you are in a method-ready state.
Similary, remember, you can get a refernce to the bean's special JNDI context in the ejbCreate,Remove,Activate and Passivate methods - but you can't use that context until you are in a method ready state - your busines methods.
So, I think there is a little bit of confusion over transactions and "getting access to" resources. Nothing stopping you from getting references - but you can't use them until the bean is transactionally ready...
Hope this helps.
-=david=-
 
Harvey Chan
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yup, I think u r correct. According to the diagram in the specification, there should not be any transaction in running ejbCreate..and etc.
But, still the same question, then why ejbCreate() method in statless cannot access other EJB, while stateful session bean can? At leaset, can get reference........... is the specification having problem??
I really want to understand it instead of memorize it..
ahah
Harvey
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Harvey,
There is a *big* difference between both stateless/steful ejbCreate() contexts :
Stateless : the *Container* just decided to create a bean, period (there is even no client).
Statefull : a *client* called for that bean to be created.
Regards,
Phil.
 
David Harrigan
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Harvey Chan,
A stateless session bean is allowed, along with a stateful session bean, to get a reference in the ejbCreate. It's just that (along with stateful session beans) it can't *do* anything with it until it's in a method-ready state - i.e., your business methods. If you try to open a connection to a db, from retrieving a DataSource reference in the ejbCreate, then an IllegalStateException should be thrown by the container.
Hope that helps to clear up the confusion. There's no problem with the spec (apart from trying to understand it - and we *all* have problems with that :-)
-=david=-
 
Magnus Stattin
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you all for your heroic effort to make sense of this
This is still kind of confusing to me though.
As Harvey point out there is a difference between what you can do in ejbCreate and ejbRemove in a Stateful and a Stateless bean. (Spec page 80 and 90, HF 196 and 228). You can access another bean and a resource manager in these methods in a Stateful but not a Stateless bean. Access means "do things with" (HF 196) so it should include open a connection to a DB.
The difference are not whether they have a meaningful transaction context, but whether they have a client security context.
According to the spec page 91


Accessing resource managers and enterprise beans is disallowed in the session bean methods for which the Container does not have a meaningful transaction context OR client security context.


It seems to be enough to have a a client security context to get access to another bean and a resource manager. Maybe this is a step towards a solution to this mystery...
/Best Regards Magnus
[ January 08, 2004: Message edited by: Magnus Stattin ]
 
David Harrigan
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Magnus,
That sounds like a very plausible reason - security checks Makes sense to me.
-=david=-
 
reply
    Bookmark Topic Watch Topic
  • New Topic