• 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

State Full Sesion Beans & Transactions

 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a confusion about transactions with statefull session beans. If i use delarative transaction does all the methods of the bean in which ever called is a single transaction???
Am totally LOST......
 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It very much depends on how you configure it in
your deployment descriptor.
1) If you use the required attribute, this means
that the method in question will be called by
the container in a transaction context,
regardless the client was involved in
transaction or not.
2) If you use the requires new attribute, the
container always starts a new transaction, when
invoking this method.
3) if you use the not supported attribute,the
method cannot be called by the container in a
transaction context.This means if a client
involed in a transaction calls this method,
the container suspends the transaction before
calling that method.
4) If you use the supports attribute, it means
the container does not have to suspend
any transaction before calling this method.
If a calling method is not involved in a
transaction, the container does not have to
start a new transaction.
5) The mandatory attribute means any client
calling this method must be involved in
transaction before calling this
method.Otherwise the container will throw
an Exception.
6) The never attribute means that bean
is not expecting a transaction. If a client
calls this bean in a transaction, the container
throws an exception, othewise the container
simply invokes this method.
Ebage
SCJP
SCEA
[ December 10, 2002: Message edited by: Christian Ebage ]
[ December 10, 2002: Message edited by: Christian Ebage ]
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Nehal,
Assuming CMT, then the functionality of your transaction will depend largely on your configuration. A transaction can span multiple method calls, or it could span none.
Since Christian responded to you with a description of each type of declarative transaction attribute, I won't repeat that here. I will however give you a simple example to try and demonstrate.
Here is the situation:
We have an EJB (doesn't matter what type) with three methods: A, B, C. Method A calls method B, method B calls method C. Therefore the chain is A->B->C. Pretty simple right? Let's look at a couple different scenarios.
Scenario 1:
Method A is marked as Required
Method B is marked as Required
Method C is marked as Supports
Scenario 1 Breakdown:
Method A is called.
Container creates a new transaction if one is not in progress.
Method B is called and joins the current transaction.
Method C is called and also joins the current transaction.
Method C returns.
Method B returns.
Method A returns.
Container commits or rollsback the transaction.
Scenario 1 Analysis:
All three method calls happened within the context of the same transaction. Had any one of them decided to rollback, then any work done on transactional resources by the other two would also be rolled back.
Scenario 2:
Method A is marked as Required
Method B is marked as RequiresNew
Method C is marked as NotSupported
Scenario 1 Breakdown:
Method A is called.
Container creates a new transaction if one is not in progress.
Method B is called.
Container creates a new transaction and temporarily blocks Method A's transaction.
Method C is called which executes outside the context of any transaction.
Method C returns.
Method B returns.
Container commits or rollsback B's transaction.
Method A returns.
Container commits or rollsback A's transaction.
Scenario 2 Analysis:
All three method calls happened within the different transactional contexts (or in the case of C, no transactional context). Had any one of them decided to rollback, then the work done by the other two would not have been affected.
The important thing to note here, is that the only difference between the two scenarios was the transactional attributes that were set on the ejb. Thus it is easy to see how powerful declarative transactioning can be in terms of developer productivity.
Does that answer your question?
 
Nehal Dave
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Christian & Chris
Thanks for ur replies. It really made my understanding clear. What i understood is that the scope of tranaction is limited to a method.
Correct me if i am wrong.
Cheers
Nehal.
 
You have to be odd to be #1 - Seuss. An odd little ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic