Hi Jim, Do you have one or multiple interfaces to your app server? We are in the situtation that we will have multiple end points for our data: our client, third party software, other internal products which want to integrate with ours, etc etc. For that reason we have felt that session beans make for a nice way to create "application views". In other words, entity beans provide the building blocks that session beans assemble to serve a particular application / consumer. The picture drawn is quite nice, but it also make sense from a performance point of view. Perhaps the most important point is that client side(FAR-OUT, in your terminology) demarcated transactions is a big no-no, performance wise. > -----Original Message----- > From: Jim Frentress [SMTP:[EMAIL PROTECTED]] > Sent: Friday, May 14, 1999 12:17 PM > To: [EMAIL PROTECTED] > Subject: Entity no more expensive than Session: WAS: > findLargeAccounts - w hy bother? > > Imre made the statement and i must admit that i tend to agree. We use > Session almost exclusively for bootstrap and client state. > > I'm less fond of "wrapping" entity with session than apparently most > posters > to this list. I have a feeling that it's because ITM is using EJB in > production so we have to solve real-life problems rather than academic > ones. > > I'm perfectly willing to be enlightened as to why I'm not properly > educated > on the topic. I can say that our system does not appear to be constrained > on > the appserver level (eg EJB) and as far as we can see, we're scalable > there > far into the future with clustering. > > So, who out there has a non-trivial system *in production* under EJB and > has > something to say about this? > > > -----Original Message----- > > From: Imre Kifor [SMTP:[EMAIL PROTECTED]] > > Sent: Friday, May 14, 1999 11:30 AM > > To: [EMAIL PROTECTED] > > Subject: Re: findLargeAccounts - why bother? > > > <snip>The > > idea is to treat both entities *and* collections of entities as "first > > class" citizens. Since entity beans are no more expensive than session > > beans, we use entities for the collections to take advantage of > > CMP/caching/sharing and to have finer control of the bean instances. As > a > > matter of fact, we use session beans in our customer's architectures > only > > when client (or session) info has to be maintained on the server. > > > <snip> > > ========================================================================== > = > 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".
