• 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
  • Devaka Cooray
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Jeanne Boyarsky
  • Tim Cooke
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
Bartenders:

few questions on entity beans

 
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
I would like to know whenever ppl talk about entity beans they talk in relation with local interfaces and not in terms of remote interfaces
why so. Is it convenience or is there a downside using entity beans with remote interfaces
like in case of cmr , we cant use cmr with remote entity beans & can onli be used with local entity beans
What i am saying is not invoking entity bean directly by the client but a Session bean on 1 app server invoking an entity bean on anohter app server

Rgrds
Manish
 
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Howdy Manish,
good questions...
There are a couple of reasons why local interfaces are perhaps more important with entity beans:
1) For one entity bean to have a CMR relationship with another bean, the entity must use the LOCAL interface of the bean for which it has a CMR field.
2) If you allow direct Remote client access to a bean, and the client is not itself another bean, then the client cannot *scope* the transaction. This means that for each method the client calls on the entity bean, there is potentially a complete cycle of starting a new transaction, ejbActivate, and ejbLoad, and THEN the method, followed by the reverse -- ejbStore and ejbPassivate. Let's say the client wants to call three business methods on the bean, and each method has a Requires tx attribute. Those 3 method calls result in:
ejbActivate
ejbLoad
BizMethodOne
ejbStore
ejbPassivate
ejbActivate
ejbLoad
BizMethodTwo
ejbStore
ejbPassivate
ejbActivate
ejbLoad
BizMethodThree
ejbStore
ejbPassivate
All that for just three method calls from the client!!
So, if the client is, say, a Session bean, then the Session bean can start the tx and make the three calls as follows:
ejbActivate
ejbLoad
BizMethodOne
BizMethodTwo
BizMethodThree
ejbStore
ejbPassivate
A huge improvement.
Now, this client tx scoping really has nothing to do with whether the client is using the local or Remote interface of the bean. But if a client *is* a session bean, then the client has the option for using the local interface of the bean, depending on your design.
The main reason, and often the *only* good reason to use local interfaces, though, is for entity bean relationships. Even in the scenario I described with a Session bean accessing the Entity bean (rather than letting the client go directly to the entity bean), there are compelling reasons to make the entity bean Remote to the Session bean -- mainly that the beans can be deployed anywhere, at any time. The session bean can be placed on another network node without causing things to break. Once you make the decision to keep beans local to one another, you're more or less stuck that way. (although there are some design hoops you can go through to try to still give yourself some location "transparency", by having a bean that uses both local and Remote interfaces and doing a bunch of stuff to make it work either way, but this is often kludgey).
Local interfaces were introduced into the spec to support CMR. Period. But because people had complained about having unnecessary overhead with RMI even when beans were in the same JVM, the spec developers decided to (under pressure) extend the local capability (but at your own design and maintenance risk) for other purposes as well, including session beans.
cheers,
Kathy
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kathy Sierra:
2) If you allow direct Remote client access to a bean, and the client is not itself another bean, then the client cannot *scope* the transaction. This means that for each method the client calls on the entity bean, there is potentially a complete cycle of starting a new transaction, ejbActivate, and ejbLoad, and THEN the method, followed by the reverse -- ejbStore and ejbPassivate.


For exam purposes this is correct. The J2EE blueprints actually leave open the possibility of client-side non-bean transactions, although normally transaction scoping would be achieved by creating a bean method to represent the desired transaction:


8.5 Transactions in Applets and Application Clients
The J2EE platform does not require transaction support in applets and application clients, though like distributed transactions, a J2EE product might choose to provide this capability for added value. So, whether applets and application clients can directly access a UserTransaction object depends on the capabilities provided by the container. To ensure portability, applets and application clients should delegate transactional work to enterprise beans.

 
I RELEASE YOU! (for now .... ) Feel free to peruse this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic