• 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 and transaction attributes

 
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
According to the HeadFirstEJB book page500, MDBs can use only two transaction states, Required (if you want a transaction) or NotSupported (if you don't want one).

In my mind, RequiresNew would behave like Required in this case, and Never (and, for that matter, Supports) would behave like NotSupported. The only ones which would be illegal would be Mandatory, since there's no way to have a pre-existing transaction.

So, my question is: Why are RequiresNew, Never and Supports illegal for MDBs?
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by �dne Brunborg:
So, my question is: Why are RequiresNew, Never and Supports illegal for MDBs?[/QB]



Never, Supports, RequiresNew are not make sense, because there isn't pre-existing transaction context for MDB.

Never throws Exception if there is pre-existing transaction context, but that don't ever occur (Use Never for what? Why don't use NotSupported)

If there is pre-existing transaction context, Supports will run in that TX context (There is NO! So, what is the point to use Supports?)

RequiresNew always run in new transaction context, but this behavior is always the same to Required. Why we need 2 attributes that always effect the same?
[ February 21, 2006: Message edited by: Kengkaj Sathianpantarit ]
 
Ådne Brunborg
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Kengkaj Sathianpantarit:


Never, Supports, RequiresNew are not make sense, because there isn't pre-existing transaction context for MDB.

Never throws Exception if there is pre-existing transaction context, but that don't ever occur (Use Never for what? Why don't use NotSupported)

If there is pre-existing transaction context, Supports will run in that TX context (There is NO! So, what is the point to use Supports?)

RequiresNew always run in new transaction context, but this behavior is always the same to Required. Why we need 2 attributes that always effect the same?

[ February 21, 2006: Message edited by: Kengkaj Sathianpantarit ]



Thanks for the reply

Let's see if I understand correctly:
- Never is not allowed because we don't need its special feature, which is to throw an Exception (or Error?) if called within a transaction - which never occurs
- Supports is not allowed because we don't need its special feature, which is to join a transaction if it exists, or run unspecified if not exists
- RequiresNew is not allowed because we don't need its special feature, which is to always start a new transaction

Seems to me that Required is chosen arbitrarily, since we don't need both... could just as easily have been
"- Required is not allwoed because we don't need its special feature, which is to join an ongoing transaction if it exitst, or create a new one. "
RequiresNew is, according to the MasteringEJB book (p.296), for "if your bean needs the ACID properties" which I would think an MDB would want.

Don't mean to be difficult here, just trying to understand and not just memorize...
[ February 21, 2006: Message edited by: �dne Brunborg ]
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think i understand this partly, but not completly for sure.

i. Never - should throw exception if a transaction was running, we cannont know that, so this is not possible.

ii. Mandatory - Not possible again for similar reason.

iii. Supports - Not possible because how would you know if a transaction was running or not.

iv. RequiresNew - Should suspend a running transaction and start new one, we don't know if TX was running, so not possible (is that right??)

v. Required - Should start new Tx only if there was no TX already, we don't know the current TS - So container always starts one for us. But if there was a TX running, we should join it, how is that possible??

vi. Not supported - Should run without TX, and suspend any existing TX, how is this possible, contradicts with point iv. right??

I am still not clear ....any help would be appriciated.

Thanks alot.

 
Ranch Hand
Posts: 257
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
MDBs are invoked by the Container. Think of the Transaction boundaries from the perspective of the MDB. When the container calls the MDB there can be a Trasaction (Requires) or No transaction (Not Supported). Other options are logically not feasible.
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
MDB are controlled by container. For container 2 options are there either start a transaction or not to start transaction(No Transaction). Start Transaction here means if pre existing transaction is there (txa), it will continue that transaction other wise start new transaction.

Container:
1) Start Transaction:

if pre existing transaction (TXA) is there, it will continue that transacation: (TXA) --> (TXA)
if no pre existing transaction is there, it will start new transaction (___) --> (TXA)

2) NO transaction

if pre existing transaction (TXA) is there, it will not support: (TXA) --> (___).
if no pre existing transaction is there, it will continue that one.(____) --> (____).


Regards,
Ramesh V



 
reply
    Bookmark Topic Watch Topic
  • New Topic