• 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

BMT Transactions

 
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In spec of 17.6.1, it says:

If the client request is not associated with a transaction and the instance is already associated with a transaction T2, the container invokes the instance with the transaction that is associated with the instance (T2). This canse can never happen for a stateless Session Bean or a Message-drive Bean.

Does the following represent the scenerio above?

Client invokes on foo,

foo {
bar()
....
}


bar {
ut.begin()
.....
ut.commit()
}

I dont think it is right. What does transaction associated with instance mean?
Any why only for SB/MDB only?

Thanks.
 
Author & Gold Digger
Posts: 7617
6
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This case can never happen with stateless session beans (SLSB) and message-driven beans (MDB) because the specification requires those beans to complete any started transaction at the latest when the method invocation returns. Since SLSB and MDB do not maintain any client-specific state, we have no guarantee that the same bean instance will serve two subsequent invocations from the same client. For this reason, transactions cannot span multiple method calls, and it is thus impossible for them to have ongoing transactions (T2) when they receive a new client request. Does this make sense?
 
Dan T
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Valentin.
I understand what you said in the last post, but im still unclear about the terminology.

Im unclear the difference between:
instance transaction
the transaction that the method runs in

Does the instance transaction mean whether the method we are about to run have a ut.begin() in it?
 
Ranch Hand
Posts: 1327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
which does entity bean not support?
CMT or BMT
 
Valentin Crettaz
Author & Gold Digger
Posts: 7617
6
IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does the instance transaction mean whether the method we are about to run have a ut.begin() in it?
Not necessarly... If the bean uses bean-managed transaction demarcation, then yes. But if the bean uses container-managed transaction demarcation, the transaction will be started transparently by the container whenever some method is invoked (as specified in the deployment descriptor).

which does entity bean not support? CMT or BMT
Entity beans MUST NOT use BMT.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic