GeeCON Prague 2014*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Transaction attributes for SLSessionBeans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Transaction attributes for SLSessionBeans" Watch "Transaction attributes for SLSessionBeans" New topic
Author

Transaction attributes for SLSessionBeans

shanthisri mocherla
Ranch Hand

Joined: Sep 05, 2005
Posts: 119
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
Rahul Mishra
Ranch Hand

Joined: Jan 22, 2006
Posts: 211
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 ]

OCMJEA/SCEA, SCDJWS, SCBCD 1.3, SCJP 1.4
My SCEA experience:http://javalogue.blogspot.com/
Ankit Doshi
Ranch Hand

Joined: Dec 04, 2002
Posts: 222
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

Joined: Jan 22, 2006
Posts: 211
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 ]
Frederic Esnault
Ranch Hand

Joined: Feb 13, 2006
Posts: 284
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?


SCJP 5 - SCWCD 1.4 - SCBCD 1.3 - Certification study documents/resources: http://esnault.frederic.free.fr/certification
Rahul Mishra
Ranch Hand

Joined: Jan 22, 2006
Posts: 211
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 ]
k space
Ranch Hand

Joined: Jun 25, 2002
Posts: 104
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.


SCEA | SCBCD | SCWCD | SCJP - The kSpace
Frederic Esnault
Ranch Hand

Joined: Feb 13, 2006
Posts: 284
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

Joined: Jan 22, 2006
Posts: 211
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

Joined: Jan 22, 2006
Posts: 211
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

Joined: Feb 13, 2006
Posts: 284
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

Joined: Jan 22, 2006
Posts: 211
Guys,

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

You"ll find your answer
Frederic Esnault
Ranch Hand

Joined: Feb 13, 2006
Posts: 284
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.
 
GeeCON Prague 2014
 
subject: Transaction attributes for SLSessionBeans