• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Couple of doubts in Session Bean

 
Ranch Hand
Posts: 120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. How can ejbActivate, ejbPassivate and ejbRemove methods in stateful Session bean, can get the transaction reference and call methods on it but cannot do CMT related transactional operation.

2. Why is ejbRemove in Stateful Session bean has different level of usage of SessionContext than Stateless Session bean. I know about the client security context, but what about transaction references and other things.

3. HFE Page 236, What does this means - "The bean class is not required to (but is allowed to) implement the bean's component interface.

Thanks.
 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Mini

1. How can ejbActivate, ejbPassivate and ejbRemove methods in stateful Session bean, can get the transaction reference and call methods on it but cannot do CMT related transactional operation.

Note fropm the spec that all these methods are running in unspecified transaction context.
For a CMT the container starts a transaction and we don't know exactly when , but we can rely on the SessionSynchronization call backs to do things just before transaction starts etc.

For BMT you are creating the transaction and then managing transaction .

So my conclusion is as these methods are not controlled by transaction you can't set rollback or get rollback in these methods.

2. Why is ejbRemove in Stateful Session bean has different level of usage of SessionContext than Stateless Session bean. I know about the client security context, but what about transaction references and other things.

from the spec" Accessing resource manager 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"


3. HFE Page 236, What does this means - "The bean class is not required to (but is allowed to) implement the bean's component interface.


Implementing component interface is bypassing the container. The container or spec won't stop you from doing it. It is allowed. But it is no more J2EE in spirit as you will be bypassing all the services the container is providing and also the body guard. It is not at all advised
 
mini mehta
Ranch Hand
Posts: 120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Originally posted by Girija Siva:
Hi Mini

--- Thanks for the answers, really appreciate your efforts, but i have some query on your answers ---

1. How can ejbActivate, ejbPassivate and ejbRemove methods in stateful Session bean, can get the transaction reference and call methods on it but cannot do CMT related transactional operation.

Note fropm the spec that all these methods are running in unspecified transaction context.
For a CMT the container starts a transaction and we don't know exactly when , but we can rely on the SessionSynchronization call backs to do things just before transaction starts etc.

For BMT you are creating the transaction and then managing transaction .

So my conclusion is as these methods are not controlled by transaction you can't set rollback or get rollback in these methods.

2. Why is ejbRemove in Stateful Session bean has different level of usage of SessionContext than Stateless Session bean. I know about the client security context, but what about transaction references and other things.

from the spec" Accessing resource manager 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"


-- According to the above, ejbRemove() in the Stateful session method doesn't have the meaningful transaction context. But even then you have resource manager access and Enterprise bean access allowed in ejbRemove of Stateful session bean but not allowed in Stateless session bean--

3. HFE Page 236, What does this means - "The bean class is not required to (but is allowed to) implement the bean's component interface.


Implementing component interface is bypassing the container. The container or spec won't stop you from doing it. It is allowed. But it is no more J2EE in spirit as you will be bypassing all the services the container is providing and also the body guard. It is not at all advised
[ June 02, 2004: Message edited by: mini mehta ]
 
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Mini,

I think the answer to your 3rd question refers to pg 86 in HFEJB. The point here is that your bean usually does not implement the component interface in the official Java sense, although as page 86 shows, you could do it this way. The recommended approach, however, is to code the methods defined in the component interface as though you were implementing the interface, but without actually doing so. Doing it this way is an example of what the book calls "bean law".

regards
Simon
 
mini mehta
Ranch Hand
Posts: 120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Simon Ingram:
Hi Mini,

I think the answer to your 3rd question refers to pg 86 in HFEJB. The point here is that your bean usually does not implement the component interface in the official Java sense, although as page 86 shows, you could do it this way. The recommended approach, however, is to code the methods defined in the component interface as though you were implementing the interface, but without actually doing so. Doing it this way is an example of what the book calls "bean law".

regards
Simon




Thanks Simon, but we already have answer for the third question. It is the 1st and 2nd question which need clarification.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic