(I'm brand new to this EJB stuff so apologies if I'm completely
off base here.)
I don't understand the all or nothing sort of scheme implied
by the commentary. Is it not reasonable to create this flow?
1 - Servlet gets data and bulks them up
2 - Servlet creates a (stateless) session bean
and passes in the bulk item. The session
bean starts the transaction (TX_REQUIRED)
3 - Sesssion bean creates the entity bean and
for each element in the bulk item calls the
appropriate setXXX() method.
As for the scenario of updating the account
data wouldn't one simply create a new session
bean which performed that operation, perhaps
accepting only the relevant parameters and
calling the appropriate setXXX() methods? I'm
not sure I'd actually do that or make the session
bean smart enough to understand how to recognize
an incomplete bulk item and only call the appropriate
setXXX() methods.
This, BTW, appears to me to be one motivator for
the notion that entity beans should "only" be accessed
via session beans.
I hope someone who knows actually what their doing
comments on this. I'm a little concerned that my
understanding of EJBisms are fundamentally flawed.
---Rick
Alex Smith <[EMAIL PROTECTED]> writes:
> 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".
>
------------------------------------------------------
Rick Kitts | The only thing worse than
Software Architect | generalizing from one example
DigitalThink, Inc. | is generalizing from no examples
===========================================================================
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".
