• 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

Transaction attributes for SLSessionBeans

 
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi friends,
can somebody please let me know which methods do we have to mark with transaction attributes in case of stateless session beans(CMT).
I guess they are the business methods in the component interface just like stateful session beans.
Is my guess correct?
one more question is which three of the six transaction attributes are dangerous.?? I guess they are mandatory and never.what is the third one??

waiting for reply

thanks
shanthisri
 
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

The answer to your first Question -

You could also mark transaction atributes on methods like Create,Remove in the Home Interface.For details refer the specs.This goes for both stateful and stateless beans.

The idea here is that there are some methods which run in the Transaction context of the method which called them.For example, afterBegin().Since its a container callback ..it will always run in the transaction context of the corresponding business method.

For the answer to your second Question - The Attributes are NotSupported,Supports,Never. The primary reason being that all these three make the transaction unspecifed in the sense that when these attributes are mentioned either the method is not run in a transaction context at all or the container is unsure if it should run the method in a transaction(Consider Supports- The method runs in a transaction if the caller was in a transaction otherwise it doesn't.Hence these three are discouraged strongly to the extent that a CMP Bean does not recommend usage of these three

[ April 19, 2006: Message edited by: Rahul Mishra ]
[ April 19, 2006: Message edited by: Rahul Mishra ]
 
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey, I guess you should not specify transaction attributes for methods in home interface ...

Check the first bulleted point on page 351 of the spec :

Transaction attributes must not be specified for the methods of a session bean�s home interface.

 
Rahul Mishra
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ok..major goof..on my part...you cant specify the transaction attributes for those methods because they dont run in a Transaction at all. But whenever they do..you can...for example in Entity Beans

Regret the slip
[ April 19, 2006: Message edited by: Rahul Mishra ]
 
Ranch Hand
Posts: 284
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes you should have specified for EntityBeans only create/remove should be "attributed".

About the dangerous attributes, I guess like shanthisri, that mandatory and never are dangerous, because they are the only ones that may throw an exception and so stop processing.

I do not see why NotSupported would be dangerous, as if some application assembler uses this attribute for a method, it means it expects the method not to run in a tx at all, and so it does not use setRollbackOnly mechanism or try to get tx information.

Why NotSupported would be considered more dangerous than an attribute that could :
- thrown an exception;
- cause the bean instance to be discarded;
- stop the current business logic processing?

I understand an UTC is not very clear and so discouraged, but this is nothing compared to a Big Bad Runtime Exception, don't you think?
 
Rahul Mishra
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Fredric,

You sound very convincing but i distinctly rememeber reading what i said..in either EJB specs or HFEJB..there was a sharpen pencil' Question on this..and in the subsequent pages ..the answer was uncovered...i will look up and attach the references...
[ April 20, 2006: Message edited by: Rahul Mishra ]
 
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

which three of the six transaction attributes are dangerous.??

This is a very interesting question.

I would say Mandotory, Never and Supports are dangerous. Out of the three, Supports is the most dangerous. If the bean provider does not use any transactional resources (e.g. database), then s/he should set it to NotSupported. If s/he uses Supports, then what is her/his intention in case of unrecoverable error, and what actions can s/he take to bring the system back to a stable state, e.g. undo the changes. Remember setRollbackOnly or system exception won't always get a consistent result.
 
Frederic Esnault
Ranch Hand
Posts: 284
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I saw on page 499 the Never, NotSupported and Supports, but this is about methods running in UTC. IS that what you mean? And where did you see this in specs?
 
Rahul Mishra
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yes, this is what i saw...and if you read those line which say..."The Container just doesnt know..if the method will run in a Transcation"..and then it goes on to point the most dangerous.

Though its not explicit..thats the reason for my answer..

i had said hfejb/specs..since i found it in HFEJB..i dont think i saw it in specs
 
Rahul Mishra
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And there is one more reason why i wouldnt include mandatory as a problem..

Most of us here have pointed out that we wouldnt like to use it because it throws an Exception

But i belive..that the idea to throw the Exception is because you ALWAYS want your client caller to have a Transaction...

It would make sense in those critical business operations and since EJB's can have various clients...it would make sense to enforce such a rule...Still disagree..get in the ring with gloves
 
Frederic Esnault
Ranch Hand
Posts: 284
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes i agree with you. If you really need a transaction, it may make sense to throw back an exception if you don't have one. You have one point

But even if I agree, I still think it's quite a huge price to pay (the full system exception consequences thing...). Maybe they could have just sent some kind of a Application exception?

IT wouldn't rollback the tx (in case of never being called with a tx), but would allow the bean developer to manage the app exception.

But well anyway, they will not change the specs for me, so I'll grip on your point
 
Rahul Mishra
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Guys,

Have a look at page 352 ..EJB Specs 2.0..

You"ll find your answer
 
Frederic Esnault
Ranch Hand
Posts: 284
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Rahul, you got the point :

In general, however, the Application Assembler
should avoid use of the NotSupported, Supports, and Never transaction attributes for
the methods of entity beans with container-managed persistence because it may lead to inconsistent
results or to the inconsistent and/or to the partial updating of persistent state and relationships
in the event of concurrent use.



Thanx for sharing, now the answer is clear.
reply
    Bookmark Topic Watch Topic
  • New Topic