• 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

MDB Transaction for listener method

 
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
MDB message listener method can have only REQUIRED and NOT_SUPPORTED type of transaction declarations.

But why is it REQUIRED and not REQUIRES_NEW?

In my understanding, MDB's are not directly called, they are invoked by the container, so there is no transaction context available for propogation. In this case it will always create a new transaction. So I don't understand why it should have REQUIRED and not REQUIRES_NEW?
 
Ranch Hand
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you think about it

In MDB, the container starts the transaction(Container Managed).

When the case is Required, the transaction is propogated to the MDB.
When the case is NotSupported, the transaction is not propogated to the MDB.

If we allow Requires_New, the bean would hold the transaction started by the client & start a new transaction. Then how would the container know that the transaction was rolledback, if it was not started by it?

 
Nikhil Jain
Ranch Hand
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you think about it

In MDB, the container starts the transaction(Container Managed).

When the case is Required, the transaction is propogated to the MDB.
When the case is NotSupported, the transaction is not propogated to the MDB.

If we allow Requires_New, the bean would hold the transaction started by the container & start a new transaction. Then how would the container know that the transaction was rolledback, if it was not started by it?
 
Nikhil Jain
Ranch Hand
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you think about it

In MDB, the container starts the transaction(Container Managed).

When the case is Required, the transaction is propogated to the MDB.
When the case is NotSupported, the transaction is not propogated to the MDB.

If we allow Requires_New, the bean would hold the transaction started by the Container & start a new transaction. Then how would the container know that the transaction was rolledback, if it was not started by it?


 
nitin pai
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Anu I think you are a little mistaken here.

REQUIRES_NEW doe not make a container hold its transaction. In fact the container starts the new transaction for the bean itself.

If you take a look at the spec, it says:


The Container must invoke a message-driven Bean method whose transaction attribute is set to Required with a valid transaction context. Because there is never a client transaction context available for a message-driven bean, the container automatically starts a new transaction before the dequeuing of the JMS message and, hence, before the invocation of the message-driven bean's onMessage(...) method.



If the container always starts a new transaction automatically, why the need of REQUIRED, why not REQUIRES_NEW?
 
Nikhil Jain
Ranch Hand
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What I meant by hold the transaction was, that the container would suspend the propogated transaction & would start a new transaction. But we don't want this here. We want a container started transaction. I think that could only be achieved by "Required". Please correct me, if I am wrong ...
 
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
well I have one explaination, are requires_new and not_supported mutually exclusive?

think abt it, if its requires_new then thr will be a transaction even whn no transaction was propagated, so not_supported will be of no use ever.

Okay thn why not_supported have to be there? coz smtimes you probably dont want a transaction, co anyhow sending message is done in different transaction altogether.

therefore only required and not_supported are there.
 
nitin pai
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Vinay Nath:
well I have one explaination, are requires_new and not_supported mutually exclusive?

think abt it, if its requires_new then thr will be a transaction even whn no transaction was propagated, so not_supported will be of no use ever.

Okay thn why not_supported have to be there? coz smtimes you probably dont want a transaction, co anyhow sending message is done in different transaction altogether.

therefore only required and not_supported are there.



Thanks Vinay, this explanation makes a really good point. I did not think in this way.
 
PI day is 3.14 (march 14th) and is also einstein's birthday. And this is merely a tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic