Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

BMT sb that doesn't use UserTransaction

 
Alex Sharkoff
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I'd like to verify one thing.

Can one have a bmt sb that uses JDBC API and does not reference javax.transaction.UserTransaction at all ? Is it legal? I could not find anything in regards to such situation in the ejb spec.

Eg,



Thank you very much for your answers.

[ October 18, 2004: Message edited by: Alex Sharkoff ]
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alex,

Basically, transactions and JDBC have nothing in common. Transactions are used to delimit the scope of database operations or other types of operations to some weird legacy system that supports transactions. You are free to not use transactions at all, but then you run the risk of messing up your database in case something wrong happens and introducing consistency problems.

You can have a look at section 17.3.3 to see how a session bean uses JDBC and transactions to make things work

I hope this helps
[ October 18, 2004: Message edited by: Valentin Crettaz ]
 
Alex Sharkoff
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Valentin, for your prompt answer. I really appreciate it.


but then you run the risk of messing up your database in case something wrong happens and introducing consistency problems.


I think the same can be said in regards to using javax.transaction.UserTransaction

I was under impression that resource-manager specific transaction demarcation API cannot be used in ejb, which is obviously not the case.

Will it be then true to say that one can have nested transactions in BMT sb provided that it uses a JDBC transaction controlled by the transaction manager of the DBMS (i.e. it does not use JTA at all, or in other words makes no use of UserTransaction)?


Thanks to all for your thoughts on this subject.
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can one have a bmt sb that uses JDBC API and does not reference javax.transaction.UserTransaction at all ?

Concerning your very first question, by definition a BMT bean is one that actually must use javax.transaction.UserTransaction for explicitly demarcating transactions (17.3.3)

What you are doing in your code is just using plain JDBC without wrapping the code within transaction boundaries. That's perfectly legal, but again, you may bring your DB into an inconsistent state if something bads happens while you execute your queries...

I'm not sure I answered your question. Feel free to smash back if necessary
 
Alex Sharkoff
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Smashing back


Concerning your very first question, by definition a BMT bean is one that actually must use javax.transaction.UserTransaction for explicitly demarcating transactions (17.3.3)


But if one does not use javax.transaction.UserTransaction at all then he/she is free to use JDBC transaction controlled by the transaction manager of the DBMS (eg, Connection#commit() in the BMT sb code.

I am just wondering whether it is possible to use nested transactions in BMT sb.
JTA (i.e. when using UserTransaction) does not allow nested transactions. Therefore, when BMT sb uses JTA it cannot dream of leveraging on nested transaction.
However, if one does not use JTA at all and goes with JDBC transaction manager then it is possible to use nested transactions in BMT sb.

Valentin, do you agree with such statement?

 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ouch !!

Well, the EJB 2.0 spec is *very* specific on the fact that EJBs do NOT support nested transactions. Moreover, it also states that the resource manager specific transaction demarcation methods (such as Connection.commit() for JDBC) must not be used while in an existing bean-managed transaction (17.3.3).

However, the spec (17.1.1) lets some room for future implementations:

Many applications will consist of one or several enterprise beans that all use a single resource manager (typically a relational database management system). The EJB Container can make use of resource manager local transactions as an optimization technique for enterprise beans for which distributed transactions are not needed. A resource manager local transaction does not involve control or coordination by an external transaction manager. The container�s use of local transactions as an optimization technique for enterprise beans with either container-managed transaction demarcation or bean-managed transaction demarcation is not visible to the enterprise beans. For a discussion of the use of resource manager local transactions as a container optimization strategy, refer to [ 9 ] and [ 12 ].


However, if one does not use JTA at all and goes with JDBC transaction manager then it is possible to use nested transactions in BMT sb

This is correct, but your beans will not be the best example of portability!
Note that 24.2.5 (JDBC 2.0 extension requirements) states that:

The EJB Container must include the JDBC 2.0 extension and provide its functionality to the enterprise bean instances, with the exception of the low-level XA and connection pooling interfaces. These low-level interfaces are intended for integration of a JDBC driver with an application server, not for direct use by enterprise beans.

[ October 19, 2004: Message edited by: Valentin Crettaz ]
 
Alex Sharkoff
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot, Valentin! Great answer!

I guess we can conclude that there is a way to use nested transactions in EJBs ( namely BMT sb and mdb or CMT ejbs that run without transaction context ). However, this way is not advisable as it defeats one of the main bean features - its portability.

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic