Hi,
in my opinion, there are at least two reasons to allow to have
different tx settings associated with different methods:
1. You can propose specialized methods of the same bean, which have to be
called in the scope of client transaction (e.g. mandatory) or which
manages a transaction itself (using container managed or bean managed
transactions). User of the bean can choose, which method is better for
him. (However, it can be useful if a client can sometimes set tx attribute
at run-time, e.g. he would call beanXY.deposit(TX_REQUIRED_NEW,amount) =
he force a container to create a transaction and to commit the call. For
now, the bean provider has to prepare set of deposit_SUP(),
deposit_REQ_NEW(), deposit_MAN(), ... methods or to deploy the same bean
more times associated with different tx attributes.)
2. Methods associated with different tx attributes rapidly differs in
performance. For example, Weblogic invokes void dummy() method associated
with the TX_REQUIRES attribute approximately in 2.20ms if the method is
called inside a client transaction and the same method associated with the
TX_REQUIRES_NEW attribute approximately in 3.50ms. In both cases,
transactional context has to be transferred from client to server. In
the latter case, a container has to suspend client's transaction, create a
new transaction and commit it, and finally resume the client transaction
when the new transaction has completed.
Marek Prochazka
-----------------------------------------------
Marek Prochazka
Charles University
Faculty of Mathematics and Physics
Department of Software Engineering
Malostranske namesti 25, 118 00 Prague 1
Czech Republic
phone: +420-2-2191 4236
http://nenya.ms.mff.cuni.cz/thegroup/
-----------------------------------------------
> IMHO this is extremely limiting. So, I was wondering, does people use
> the possibility to have different tx settings on different methods in
> the same method, or do you only use them on a component level?
> I'm setting tx attributes on the method level. Most often it is to distinguish
> between methods that are to be runned within a tx and methods, like getter that
> doesn't need a tx. Why? My thought was that the container would have lesser
> overhead when running these no-tx methods. I also have one EJB entity component
> that when created always have to have the tx commited, but the rest of the
> method may be called within an ongoing tx. So i think there is a need to be
> able to specify tx on the method level.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
