When should we use session beans verses allowing the client to access entity beans directly. I'm faced with this design decision and it will be helpful to get your insights. I am inclined towards just using Entity beans and not creating session beans unnecessarily unless my object model really shows an operational object that is short lived and really exists to facilitate operations and will provide simple operations dealing with multiple entity beans. The shopping cart , trader and teller are good examples when we need a session bean but my scenario is : A user looking up a custom order , getting it's custom spec , changing the custom product spec , changing the shipping address on the order and then logging out. Another scenario is creating such a custom order. All our transactions are client demarcated and long lived. Should I a). let the client start a transaction , interact with all 4-5 entity beans and then do commit. If I use optimistic concurrency I won't be locking up too many objects though there are higher chances of the commit failing but we don't forsee that happening too much. b). Create a session bean called something like OrderManager and provide methods that will interact with the entity beans and may make the client's work a little easier to do but at times will also pass entity beans to the client and the client will change the attributes on the entity bean(say CustomOrder) directly. c) Same as b but will not pass any entity beans to the client and will have to provide delegated methods for modifying attributes/fields of several entity beans . So we might have to create a setOrderInfo( _ _ _ )method on the session bean which calls the settor methods on Order. I think this option has too much overhead. Thanks. =========================================================================== 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".
