• 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

Question on TX attributes

 
Ranch Hand
Posts: 372
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am unable to understand how the app assembler can decide the transaction attributes for an application if he is not going to look into the Bean Provider's source code. For example, If a Bean A method calls a Bean B method, the app assembler won't know unless he looks into the code and sees that method call. How can he decide the transaction attributes without looking at the code? For example, if method A is given Never Tx attribute and method B Mandatory, it would break at runtime.
I understand that for component-based development, the app assember needs to decide TX attributes bcos he would mixing and matching beans for different applications and would want to get different transactional behaviours for different applications. I just can't understand how that can be done without looking at code. The Bean Provider's deliverable is just an ejb-jar file which would have the class files and DD, not the source files.
 
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ever heard of something called "documentation"?
Writing doc sucks, I know, but it is necessary to communicate essential things about your application, component and so on to other people envolved in the whole process of building a stable application.
 
B.Sathish
Ranch Hand
Posts: 372
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yes Frank I agree, but I had this doubt because normally we write javadoc comments which go into the source code which is not shipped to the app assembler. So you mean to say that the Bean Provider needs to prepare, say a word document and send it to the app assembler? What if he does not know the app assembler at all? Where can he put the doc if according to the spec, the bean provider's only deliverable is the ejb-jar which is not supposed to contain docs. Well, atleast the spec does not talk about such exchanges between the bean provider and app assembler
 
Frank Ertl
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think that the spec does not mention this in detail, because it's obvious that somethings need documentation.
Like every other piece of software that's delivered with some information regarding the use of it, an ejb.jar needs the same. You can do it in javadoc and generate an API-documentation, although this is meant for other developers not the assembler. But as far as I remember there's a whole lotta "description"-tags in the DD. Here's the best place to put things in for the assembler. So the poor guy knows about what he might do and what he better avoids...
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"If a Bean A method calls a Bean B method, the app assembler won't know unless he looks into the code and sees that method call"

Actually, the App Assembler will know because the Bean Provider will have to have an ejb-ref in the DD so he can do a JNDI lookup to Bean B from Bean A. They App Assembler and Deployer will take care of the correct bindings within the J2EE app.
 
B.Sathish
Ranch Hand
Posts: 372
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yes, but the app assembler can't know exactly which method is called from which method. He can only know that a bean needs another bean. Tx attributes are at the method level. I think documentation is the only way this can be sorted out.
 
Gareth Llewellyn
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guess thats what the optional <description> element should be used for to convey this info from Bean Provider to App Assembler etc. As the DD is the only REQUIRED piece of "documentation" delivered by the Bean Provider, that is all you could count on. But the Bean Provider may not bother telling you the relevant method info, and thus you are right, formal Bean documentation would have to accompany the ejb jar to document its inter-bean dependencies.
 
B.Sathish
Ranch Hand
Posts: 372
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Which description element in the DD can the Bean Provider use to tell the app assembler about this? The container-transaction goes inside assembly-descriptor and is created by the app assember. Can you think of a specific description element in the DD where the Bean Provider can put some info related to transactions if he needs to convey something to the app assembler? For example, if he wants to tell the app assembler- method A calls method B, so better do not mark B as mandatory and A as Never. I cannot think of any <decription> tag in the DD that suits this information. I think only bean documentation outside of the spec can help.
 
Frank Ertl
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Look at this (part of the DTD for the 2.0 spec):


<!ELEMENT container-transaction (description?, method+, trans-attribute)>

<!--
The description element is used to provide text describing the parent
element. The description element should include any information that
the enterprise bean ejb-jar file producer wants to provide to the consumer of
the enterprise bean ejb-jar file (i.e., to the Deployer). Typically, the tools
used by the enterprise bean ejb-jar file consumer will display the description
when processing the parent element that contains the description.

 
B.Sathish
Ranch Hand
Posts: 372
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yes, but the container-transaction element is created by the app assembler and NOT the bean provider. So, the app assembler can put in description for the deployer. But I am looking for a tag where the bean provider can put in transaction related info that he needs to convey to the app assembler. ie a tag in the <enterprise-beans> portion of the DD and NOT the <assembly-descriptor> part. I don't think there is any tag that suits this purpose. If the bean provider and app assembler are not closely related, the app assembler has to rely on external documentation. Hence, I hold my previous stand
 
Frank Ertl
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Who says that the container-transaction-element is to be created by the app-assembler?
It is to be filled with the method-permission-elements and so on. So I think that the bean provider can write the description-element to provide the information the assembler needs.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic