Alex,
The container managed transaction paradigm does assume that the scope of
a transaction is the that of the originating method. The typical pattern
of use is that a course grained method initiates the transaction and
then, if needed, uses finer grained method calls within the transaction.
A component that initiates CMTs is typically in a different tier than
its client. At tier boundaries course grained methods are typically
used. One convention often used is to provide the client with a helper
class that aggregates info and then makes the cross tier call. This
convention gives the designer of the tier the freedom to tweak the
tier's course grained interface for performance reasons without
affecting its clients.
Architecting multi-tier apps is not simple. It's a good idea to give
yourself some extra flexibility.
-- Mark
Alex Smith wrote:
>
> Hello all,
>
> I have an entity bean, let's say Account with the following interface:
>
> public interface Account extends javax.ejb.EJBObject {
> public void setName(String name);
> public void setAccountNumber(String acctNum);
> }
>
> and in the deployment descriptor of the AccountBean these
> methods have the transaction attribute of Required. My client
> is a servlet that reads account name and number from the
> HTTP request, finds and/or creates an Account and calls
> the above setXXX methods. The requirement is that both
> calls be part of the same transaction but the only way
> to achieve that in this scenario is either 1) Use bean-managed
> transactions (not recommended) or 2) Wrap the calls with a
> stateless session bean whose method accepts parameters for all setXXX
> methods or 3) Provide a bulk accessor/mutator method.
>
> Method (2) works for scenarios when the number of parameters
> that have to be passed to various setXXX methods is small but what
> if the above Account interface had many methods all of which had to be
> invoked in this transaction:
>
> public interface Account extends javax.ejb.EJBObject {
>
> public void setName(String name);
> public void setAccountNumber(String acctNum);
> public void setOwner(String owner);
> public void setBalance(BigDecimal balance);
> public void setCreationDate(Date crDate);
> public void setExpirationDate(Date exDate);
>
> // ... and so on
> }
>
> The stateless session bean's interface would have to be extended
> to include the entire set of parameters passed to Account's
> setXXX methods:
>
> public interface BankAssociate extends javax.ejb.EJBObject {
>
> public void setupAccount(String name, String acctNum, ... );
> }
>
> It seems that the only viable alternative is a bulk accessor/mutator
> method (3) with value objects:
>
> public class AccountValue implements ValueObject {
>
> public String name;
> public String acctNum;
> }
>
> public interface Account extends javax.ejb.EJBObject {
>
> public void setName(String name);
> public void setAccountNumber(String acctNum);
> public void setAccountValue(AccountValue acct);
> public AccountValue getAccountValue();
> }
>
> This works as intended but begs the question: what are
> setXXX methods doing in the Account interface if they cannot *really* be
> part of the same container-managed transaction if invoked separately from a
> non-transactional client?!
>
> Furthermore consider a scenario where the bulk accessor/mutator methods are
> added to the interface to solve the problem outlined above but (supposedly)
> only once: when the account is being set up (all properties are required).
> The day after the account has been created, the account owner wishes to
> modify his name and extend the expiration date. This translates to two
> setXXX method calls...but they cannot be part of the same transaction unless
> routed through the bulk mutator method.
>
> Is this a shortcoming of the specification or am I missing something here?
>
> Thanks,
>
> Alex Smith
> INSight LLC
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
> ===========================================================================
> 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".
===========================================================================
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".
